Как предпринимателю управлять разработчиками

Стартаперы без опыта работы в ИТ регулярно спрашивают меня: «Слушай, а как правильно управлять программистами? Почему они все делают так медленно?» Как программист и предприниматель, я решил написать эту инструкцию, поскольку хорошо представляю ситуацию с обеих сторон. Она вряд ли поможет вам в разы ускорить разработку, но по крайней мере вы начнёте понимать, почему всё происходит именно так.

Воспринимайте разработку как процесс

«Нетехнари» часто думают, что главное — написать подробное техническое задание для разработчиков, а после этого остаётся только строго спрашивать выполнения сроков. Да, это важно. Например, помимо описания функциональности в техническом задании должны присутствовать макеты экранов с полностью законченным дизайном и тексты всех сообщений, которые будут показаны пользователю, потому что передавать дизайн и копирайтинг в разработку — плохая идея. Но хуже всего, обсудив с разработчиками функциональность, отстраниться и спокойно ждать результат. Разработка — непрерывный процесс, и вы должны чётко понимать, над чем в данный момент идёт работа, а что ещё остаётся сделать. Чем глубже вы влезли в этот процесс, тем больше вероятность, что вы сможете вовремя заметить, когда что-то пойдёт не так.

Сосредоточьтесь на главных функциях

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

Недавно мы добавляли дополнительные колонки в одном из отчётов нашего сервиса. Сделано это было за неделю, но реализацию сортировки не удалось сделать и за две. В результате мы просто убрали возможность сортировки, фактически выкинув две недели работы. При идеальном управлении это решение надо было принять через два-три дня.

Не добавляйте новых задач в процессе разработки

После того как вы погрузитесь в процесс разработки и получите возможность видеть промежуточные результаты, у вас появится сильное желание добавлять и менять функциональность на ходу. Не делайте этого никогда! Добавление и изменение требований по живому сильнее всего затягивает сроки разработки: частично реализованную функциональность намного труднее изменить. В 95% случаев лучше остаться в рамках первоначального плана и проверить новую фичу в том виде, в каком она была задумана, на живых пользователях. А потом уже вносить изменения на основании фидбэка.

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

Контролируйте усилия разработчиков

Со временем у вас появляется собственная оценка того, сколько на самом деле занимает задача, и она будет более точной, чем у команды разработки. Например, я знаю, что новые функции в «МоемСкладе» делаются довольно быстро, а переделка старых, когда надо конвертировать существующие данные пользователей, всегда медленная и мучительная. Научиться представлять более-менее реальные сроки не так сложно, сложнее на них влиять.

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

Сортируйте задачи и не ставьте их одновременно

Задачи команды разработки довольно чётко делятся на масштабные (сделать новую функцию) и мелкие (подправить форму регистрации). Общее правило — никогда не отвлекать разработчика с большой задачи на решение мелких, пусть даже срочных. Есть уникальные специалисты, которые могут эффективно работать в таком режиме, но у большинства разработчиков от постоянного переключения между задачами резко падает производительность. Имеет смысл устраивать чередование — сначала большая задача, потом неделя мелких. Мелкие задачи надо фиксировать по мере их появления, но отдавать их в разработку списком, когда планируется очередная итерация или релиз.

Каждый разработчик индивидуален

Разница в производительности между отдельными разработчиками может быть огромной. В некоторых исследованиях (например, Productivity Variations Among Software Developers and Teams: The Origin of 10x) производительность лучших и худших программистов с приблизительно одинаковым опытом различалась в десять раз. Вам надо понимать, что один и тот же человек может демонстрировать отличную скорость на задачах одного плана (например, расширения интерфейса) и катастрофически низкую на других (масштабные задачи на серверной стороне). Поэтому каждому надо давать задачи, с которыми ему комфортно работать. В противном случае производительность будет падать.

Будьте помощником разработчиков

Есть важная вещь, которая поможет вам говорить с разработчиками на одном языке. У большинства технических людей мозг работает очень рационально и организованно: то, что они делают, должно укладываться в логичную схему. Но эта схема не всегда будет удобна для ваших пользователей. Я помню, как на обсуждении страницы приёма платежей один из моих коллег сказал: «Я смогу сообщить, как она будет выглядеть, когда нарисую связи между платежами и заявками в базе данных». У вас как нетехнического человека есть преимущество — вам проще выйти за рамки, которые подсказывает реализация, и подсказать разработчикам нужное видение. Но помните: чтобы донести свою точку зрения до команды разработки, вам придётся доказать правильность своих идей с помощью логических доводов.

Закладывайте время на внутренние изменения

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

Задачи по техническому долгу необходимо планировать и выполнять, но как найти правильный баланс между ними и развитием продукта? Ваш фокус как фаундера и нетехнического человека будет смещён на новые фичи. Разработчики же склонны бесконечно улучшать существующий код и с меньшим энтузиазмом относятся к новой функциональности. Поэтому вам всё-таки придётся хотя бы на базовом уровне разобраться в технологии и устройстве вашего продукта, чтобы в обсуждениях с разработчиками найти баланс. Я стараюсь, чтобы задачи по техническому долгу занимали около 20% рабочего времени команды и шли параллельно с разработкой новой функциональности и исправлением багов.

Изучайте технологии

Для развития продукта вам придётся изучить не только его устройство, но и технологии в целом — хотя бы на базовом уровне. Например, в 2010 году нам казалось неплохой идеей использовать для разработки интерфейса своего продукта Microsoft Silverlight. Он обеспечивал кроссплатформенность, но при этом не страдал от недостатков браузерных веб-интерфейсов. Но теперь, когда поддержка Silverlight прекращена, нам пришлось бы полностью переписывать клиентскую часть на другую платформу, потратив на это массу времени. К счастью, мы заранее оценили вероятность, что новая платформа Microsoft «не взлетит», как достаточно высокую и не стали ориентироваться на неё.

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

Подводя итог — для фаундера всё-таки невозможно обойтись без погружения в технологии и процесс разработки. Эти знания дадут вам лучшее понимание того, как развивается ваш проект.