Двадцать лет я проработала в финансовой сфере, а потом решила кардинально изменить направление деятельности и основала технологический стартап. Как показала практика, человек, не имеющий опыта управления разработчиками, сталкивается с огромным количеством препятствий, особенно в начале. Но помочь в управлении новым коллективом в незнакомой сфере может синергия разных областей знаний.
Особые люди
Высокомерие и социофобия — первое, с чем вы столкнетесь, взявшись за управление новым для вас коллективом. Надо понимать, что профессию программиста зачастую выбирают те, кому комфортнее общаться с машиной, а не с человеком, и чтобы завоевать их уважение, придется хорошо потрудиться. Несомненно, вам нужна техническая экспертиза, так что приготовьтесь завести аккаунт на «Хабре» (крупнейшем на постсоветском пространстве интернет-сообществе ИТ-специалистов), к посещению тематических конференций и форумов или даже курсов по программированию. Без способности продемонстрировать достаточный уровень компетенции в области, в которой вы работаете, вам может не хватить профессионального авторитета, что может помешать вашему успеху в управлении. От вас требуется уважение к тем, кем вы управляете, и часть этого уважения должна быть заработана вашей экспертизой в бизнесе.
И если с высокомерием можно бороться повышением собственной компетенции, то социофобия представляет особую опасность, потому что о проблемах вы будете узнавать в самый последний момент, зачастую тогда, когда вы уже не сможете ни на что повлиять. Важно удержать контроль в своих руках, а не делегировать его кому бы то ни было, потому что именно социофобия команды при недостаточном контроле со стороны руководителя может вылиться в две крайности, одинаково губительные для любого ИТ-проекта: затягивание сроков и накопление технического долга. Мне «повезло» повстречаться с обоими из них.
Время не деньги
Время — деньги, но не для разработчиков программного обеспечения, во всяком случае. Программиста практически не мотивирует результат по сравнению с самим процессом. Постоянное стремление к самосовершенствованию и осваиванию новых методов кодинга приводят к тому, что ваши сотрудники будут обучаться за ваш счет, используя далеко не самые эффективные и быстрые приемы. Зачастую под какую-то достаточно приземленную задачу изобретается велосипед ценою в увеличение сроков в два, а то и в три раза. Будьте готовы, что ваши подчиненные будут искренне не понимать, почему нельзя отодвинуть срок, чтобы улучшить качество продукта.
Однако полностью отнимать пространство для творчества неправильно, а то и вовсе чревато уходом уставших от рутины ключевых специалистов в более «интересные» проекты. В таком случае велик риск того, что оставшаяся команда будет не в состоянии не только развивать, но и поддерживать проект.
Долг платежом красен
Другой бомбой замедленного действия является появление технического долга или плохо написанных вследствие сжатых сроков участков кода, обслуживание которых впоследствии заставит снова потратить столько же времени на разработку. Неудачная архитектура сродни программе, написанной человеком на языке, который знает только он сам. Вникнуть в него и поддерживать такой код, потребует существенных временных затрат, а соответственно, и денежных — это буквально парализует работу над проектом в ущерб текущему развитию до тех пор, пока неудачный участок не будет переработан.
Верхушка айсберга
Как правило, начинающие руководители технических стартапов сталкиваются со всеми возможными трудностями сразу. И корень проблемы здесь — неверная оценка всего объема задач. Руководитель, не имевший опыта в области программирования, не видит всей глубины айсберга, а лишь ее верхушку — в виде функционала конечного продукта.
Поэтому я для себя нашла оптимальным разбить все задачи разработки на бизнес-задачи, то есть те, которые диктуют клиенты и инвесторы, и задачи внутренней оптимизации — те задачи, о которых вам расскажут ваши разработчики — всевозможные улучшения, фиксации багов и прочее. Нужно отделить задачи, важные для бизнеса и не терпящие смещения сроков, от задач, которыми приятно заняться вашим сотрудникам.
Первая группа задач, как правило, более требовательна к срокам, поэтому их завершение неплохо привязать к каким-то значимым презентациям или другим событиям. Цель — обозначить то, что перенос сроков недопустим в принципе.
Вторая группа задач может иметь более размытые сроки и обеспечивать «погашение» технического долга, накопленного во время забегов с бизнес-задачами. Грамотно чередуя подобные этапы разработки, можно добиться того, что предсказуемые сроки не погубят качество вашего продукта, а команда оценит предоставленную вовлеченность в планирование задач и возможность для профессионального развития.