Руководители без технического бэкграунда часто думают, что главное — написать подробное техническое задание для разработчиков, а после этого останется только попросить строго соблюдать сроки. Да, это важно.
Помимо описания функционала, в техническое задание должны быть включены макеты экранов с полностью готовым дизайном и тексты всех сообщений, показываемых пользователю, т. к. оставлять дизайн и копирайтинг на разработку ПО — плохая идея. .
Но хуже всего, обсудив функционал с разработчиками, стоять в стороне и спокойно ждать результата. Разработка программного обеспечения — это непрерывный процесс, и вам нужно четко понимать, над чем вы работаете в данный момент и что еще осталось сделать. Чем глубже вы погружаетесь в процесс, тем больше вероятность того, что вы заметите, когда что-то пойдет не так.
Сосредоточьтесь на основных функциях
Чем может помочь такое погружение? Одной из наиболее распространенных причин срыва сроков являются неожиданные трудности с реализацией мелких и не очень важных функций. Хорошие разработчики стремятся делать хорошие продукты, а это означает реализацию всех указанных в спецификации элементов. Как идеолог продукта, вы можете и должны исключить из плана все второстепенные функции, если они начинают занимать слишком много времени, т. е. больше нескольких дней.
Не добавляйте новые задачи во время разработки программного обеспечения
Как только вы погрузитесь в процесс разработки и получите возможность увидеть промежуточные результаты, у вас появится сильное желание добавлять и изменять функциональность на лету. Никогда не делай этого! Добавление и изменение требований в реальном времени является самым большим препятствием на временной шкале разработки; частично реализованный функционал гораздо сложнее изменить.
В 95% случаев лучше остаться в рамках первоначального плана и протестировать задуманную новую функцию на живых пользователях. А затем внести изменения на основе обратной связи.
Контролируйте усилия разработчиков
Со временем вы оцените, сколько времени занимает задача, и она будет более точной, чем команда разработчиков программного обеспечениярезультаты. Например, новые функции добавляются относительно быстро, а перепроектирование старых функций при преобразовании существующих пользовательских данных всегда происходит медленно и мучительно. Научиться ставить более-менее реалистичные сроки не так уж и сложно; на них труднее повлиять.
Перфекционизм — психологическое качество, отличающее хороших разработчиков от плохих. Это относится не только к видимым экранам результатов и кнопкам, но и к внутренней реализации продукта, то есть к коду.
Например, вам нужно добавить механику бонусных действий на странице оплаты. Хороший разработчик сможет за неделю реализовать механизм поддержки любого действия, администрируемого из панели администратора, с настраиваемыми условиями, временем и так далее.
Но вам нужно быстрое решение, чтобы запустить акцию завтра и навсегда выбросить этот код через неделю. Вам нужно понять, какие компоненты останутся в вашем продукте на долгое время, а какие могут быть реализованы для разовых целей, и четко сообщить об этом команде разработчиков программного обеспечения.
Сортируйте задачи и не ставьте их все одновременно
Задачи для команды разработчиков ПО делятся на большие (сделать новую фичу) и малые (поправить форму регистрации). Общее правило — никогда не отвлекать разработчика от огромной задачи на решение маленькой, пусть даже срочной.
Некоторые уникальные специалисты могут эффективно работать в таком режиме, но у большинства разработчиков резко снижается производительность из-за постоянного переключения между задачами. Поэтому есть смысл устроить чередование — сначала огромное задание, потом неделю мелких задач. Записывайте небольшие задачи по мере их появления, но отдавайте их в разработку программного обеспечения, чтобы включить их в список, когда планируется следующая итерация или выпуск.
Каждый разработчик отличается
Разница в производительности между отдельными разработчиками может быть огромной. Например, в некоторых исследованиях версии лучших и худших программистов с примерно одинаковым опытом различались в десять раз.
Нужно понимать, что один и тот же человек может показывать отличную скорость на задачах в рамках одного плана (например, расширения интерфейса) и катастрофически низкую скорость на других задачах (крупномасштабные серверные задачи). Поэтому каждому нужно давать задачи, с которыми ему удобно работать. В противном случае производительность упадет.
Быть помощником разработчиков
Важная вещь поможет вам говорить на одном языке с разработчиками. У большинства технических людей очень организованный и рациональный мозг; они укладываются в логическую схему. Но эта схема не всегда будет удобна для ваших пользователей.
Как нетехнический человек, у вас есть преимущество — вам проще выйти за рамки, которые предлагает реализация, и донести до разработчиков правильное видение. Но помните: чтобы донести свою точку зрения до команды разработчиков программного обеспечения, вам придется доказать правильность своих идей с помощью логических аргументов.
Выделите время для внутренних изменений
Нужно помнить, что есть трудоемкие задачи, которые вы не видите со стороны ни в одном проекте, но вы должны их выполнять. Это так называемый технический долг. Как он образовался? По мере добавления новых возможностей проект обрастает костылями и подпорками.
Многие задачи решаются быстро, но ненадежно. Например, если вы регулярно не приводите свой код в порядок (этот процесс называется рефакторингом) и не развиваете архитектуру проекта, через какое-то время у вас постоянно будут расти ошибки.
Они могут возникать при добавлении новых функций или даже при исправлении старых ошибок. Если вы не потратите время на разработку архитектуры проекта, вы рано или поздно не справитесь с растущим числом пользователей.
Задачи по техническому долгу необходимо планировать и выполнять, но как найти правильный баланс между ними и разработкой продукта? Естественно, ваше внимание как спонсора и нетехнического специалиста сместится на новые функции. Но, с другой стороны, разработчики склонны бесконечно улучшать существующий код и с меньшим энтузиазмом относятся к новым функциям.
Поэтому вам все равно придется хотя бы на базовом уровне понимать технологию и структуру вашего продукта, чтобы найти баланс в обсуждениях с разработчиками. Технические задачи должны занимать около 20% рабочего времени команды разработчиков программного обеспечения и сопровождаться разработкой нового функционала и исправлением ошибок.
Узнайте о технологии
Чтобы разработать продукт, нужно изучить его структуру и технологию в целом хотя бы на базовом уровне. Это жизненно необходимо, потому что технология может быть еще жива, но не совсем подходить для ваших задач. И зачастую это невозможно выяснить до запуска системы в боевом режиме — с реальными пользователями и под большими нагрузками.
Подводя итог, без погружения в технологии и разработку программного обеспечения в качестве спонсора по-прежнему не обойтись. Более того, эти знания дадут вам лучшее понимание того, как развивается ваш проект.
