The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Аутсорсинг программного обеспечения - это то, на что вы обращаетесь, когда вы хотите создать программный продукт, но программная инженерия не является вашим основным навыком. Это умная бизнес-практика, которой придерживаются все, начиная от владельцев персональных веб-сайтов с бюджетом в $1,000, до крупных корпораций Fortune 100. И все они, в той или иной степени, сталкиваются с неудачами. На самом деле, очень сложно избежать неудач. Вот мой список простых советов для всех, кто решает аутсорсить разработку программного обеспечения (самые важные советы находятся в конце). Как мне хотелось бы, чтобы кто-то дал мне этот список 15 лет назад.
Имейте договор “Work for Hire”. Убедитесь, что контракт с командой аутсорсинга программного обеспечения включает что-то вроде этого: “Стороны считают все результаты работы, созданные разработчиком, “работой по найму”, как это определено в Законе об авторском праве США”. Это самое короткое и простое определение “все, что вы создаете для меня, принадлежит мне”. Включите это в контракт, и компания-аутсорсер не сможет утверждать, что созданное ею программное обеспечение принадлежит ей, что случается то тут, то там.
Владейте своим репозиторием исходного кода. Убедитесь, что репозиторий исходного кода находится под вашим контролем. Лучший способ сделать это - создать приватный репозиторий на GitHub за $7 в месяц. Репозиторий будет видимым и доступным только для вас и вашей команды по аутсорсингу. Более того, убедитесь, что у команды есть только доступ для чтения и они не могут изменять код напрямую, кроме как через запросы на слияние. В Git есть возможность удалить всю историю с помощью единственной “принудительной” операции push в ветку master. Поэтому для вас было бы лучше быть единственным человеком с правами на запись. Чтобы упростить жизнь, я рекомендую использовать Rultor в качестве инструмента для полуавтоматического слияния этих запросов на слияние.
Регулярно собирайте метрики. Просите участников вашей команды по аутсорсингу программного обеспечения регулярно собирать метрики от создаваемого ими программного обеспечения и отправлять вам их каким-то образом (например, по электронной почте). Я бы рекомендовал использовать Hits-of-Code, покрытие модульными тестами (или просто общее количество модульных тестов), количество открытых и закрытых задач и продолжительность сборки. Я говорю о метриках процесса. Это не то, что вы уже получаете от NewRelic. Эти метрики будут измерять производительность команды, а не разрабатываемого продукта. Я не говорю, что вы должны управлять командой по метрикам, но вы должны следить за этими числами и их изменениями.
Проводите независимые технические обзоры. Я уже писал об этом в своей статье “Вам действительно нужны независимые технические обзоры!” несколько месяцев назад. Важность таких обзоров сложно переоценить. В случае аутсорсинга программного обеспечения, они особенно важны. На самом деле, это лучший и, вероятно, единственный способ получить объективную информацию о программном обеспечении, которое вы получаете от аутсорсера. Не полагайтесь на отчеты, обещания, гарантии и обширную документацию. Вместо этого, наймите кого-то на почасовой основе и попросите этого человека просмотреть то, что разрабатывает ваш аутсорсинговый партнер. Проводите такие обзоры регулярно и систематически. Не бойтесь обидеть ваших программистов. Честно объясните им замечания рецензента. Если они профессионалы, они поймут и уважат ваши бизнес-цели. Вы также можете показать им эту статью.
Автоматизируйте и контролируйте развертывание. Просите вашу команду по аутсорсингу программного обеспечения автоматизировать весь процесс развертывания и держать его под вашим контролем. Я бы порекомендовал сделать это в первые дни проекта. Это означает, что продукт должен быть скомпилирован, протестирован, упакован, установлен и развернут в производственный репозиторий (или сервер/ы) одним щелчком мыши. Для этого должен быть создан некий сценарий, автоматизирующий эту цепочку операций. Это то, что ваш аутсорсер должен создать для вас. Затем, когда начинается разработка, каждый раз, когда в репозиторий вносится новое изменение, которое должно быть развернуто в производство, должен выполняться тот же самый сценарий. Здесь важно то, что вы должны знать, как работает этот сценарий и как его запустить. Вы должны иметь возможность собрать и развернуть свой продукт самостоятельно.
Требуйте еженедельных релизов. Не ждите финальной версии. Просите вашу команду по аутсорсингу программного обеспечения выпускать новую версию каждую неделю. Неважно, насколько интенсивно ведется разработка и сколько функций находится в процессе разработки, всегда возможно упаковать и выпустить новую версию. Если разработка действительно интенсивная, попросите вашу команду использовать GitFlow или что-то подобное для изоляции стабильной производственной ветки от веток разработки. Но не ждите! Уб
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-17 at 14:37
