В этой главе

• Управление проектами и информирование бизнеса о ходе работы (как успешном, так и нет)

• Развитие методов разработки в условиях роста команды

• Управление качеством и тестирование для обеспечения беспроблемных релизов

• Как избежать привязки решений к требованиям одного клиента

Многие технические директора приходят из инженерной среды, в которой они занимались проектированием и разработкой ПО. В этой среде они развивались и делали карьеру, по мере того как брали на себя все более крупные проекты и бˆольшую ответственность. У разработчиков есть собственные подходы и способы оставить в работе свой след. Это и привлекает в нашей сфере деятельности – свобода творчества, выбора средств реализации каждой из задач. Но когда дело доходит до формирования команды и роста компании – приходится выходить за пределы этих представлений и мыслить шире, уже с коллективной, а не индивидуальной точки зрения. Решение, которое сегодня кажется изобретательным и крутым, в будущем придется с большими усилиями поддерживать и адаптировать к изменениям.

В этой главе основное внимание уделяется важным вопросам, на которые технический директор, прошедший путь от разработчика до руководителя, должен как можно скорее обратить внимание, потому что их решение заложит основы для успешного дальнейшего развития проекта. Как и многие темы этой книги, каждый вопрос здесь представляет собой отдельную дисциплину. Техническому директору не обязательно в совершенстве владеть каждым из них, но он должен иметь представление о них и о том, какую роль они играют в работе команды. Вы должны систематизировать и привести к готовому для промышленной эксплуатации виду все: от управления проектами и информирования о ходе работ (чтобы бизнес мог положиться на вас и вашу команду в том, что продукт будет выпущен в срок) до профессионального и предсказуемого управления релизами.

Простые вещи, например создание единых стандартов написания кода, сделают код более читабельным и таким образом упростят работу с ним. И каждый из таких небольших шагов в значительной степени влияет на вашу работу. Мы также рассмотрим, как создать стандартный процесс сборки продукта, чтобы выпуск каждого обновления не превращался в кошмар для бизнеса.

В целом эта глава посвящена созданию профессионального, стандартизированного и надежного процесса разработки, который позволит подключать новых сотрудников и получать от них первые результаты уже за несколько часов или дней, а не за недели, которые ушли бы у них на преодоление подводных камней и борьбу с устаревшими методами работы.

Заметки с полей

Продакшен, управляемый разработчиком

Красивый и качественно сделанный сайт может скрывать под собой целый мир хаоса, заплаток и костылей. Один из аудитов due diligence, в которых я участвовал, напомнил мне, что ошибки при принятии простых решений в начале работы могут стоить миллионы (буквально) долларов в будущем. У SaaS-компании, о которой идет речь, был отличный продукт, но технический директор не установил никаких стандартов и не внедрил процессы выпуска релизов. Результатом стал полный бардак в коде и библиотеках. Релизами занимался только один человек (сам CTO). Не приведя работу команды к виду, необходимому для промышленной эксплуатации, технический директор создал такой большой технический долг, что стоимость исправлений оказалась равна стоимости компании. У этого технического директора просто не было знаний за пределами его опыта разработчика, необходимых, чтобы управлять растущей командой.