Планирование разработки ПО

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

Виталий Темненко, архитектор.

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

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

Человеку, планирующему разработку программного обеспечения, приходится быть архитектором. Лет двадцать назад я читала книгу о том, что метод проектирования «снизу вверх», от деталей к конструкции, постепенно изживает себя, и приходит эпоха проектирования «сверху вниз». Эта эпоха длится и по сей день.

Напишу пару слов, что же произошло со столь популярным какое-то время назад методом планирования «снизу вверх». В те дни многие программы в те дни проектировались «снизу», исходя из возможностей техники — от подпрограмм к работающему комплексу. Трудно поверить, но в 105 команд моего калькулятора я втискивала Star Trek, в котором Энтерпрайз и корабль клингонов обращались вокруг массивного оранжевого солнца. Когда один корабль попадал из лазера в другой, на цифровом экране появлялось торжествующее ЕГОГГ — сообщение о последней ошибке неудачливого экипажа. Сегодня моя игра не была бы написана, так как её утопили бы вопросами о конкурентных преимуществах, уникальных идеях, монетизации и модели распространения. Так как в наши дни программирование уже не увлечение или научное исследование, а хорошо оплачиваемое промышленное производство, то успешному архитектору приходится думать о задачах «сверху», с позиции бизнеса. Обычно это означает, что задачу требуется понять и решить «быстро, дёшево и качественно».

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

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

В заключение пара советов читателям-программистам, которые собираются планировать свои проекты. Уверена, худо-бедно, но техническую часть Вы спланируете, даже если с непривычки втрое ошибётесь по срокам. Этого недостаточно. Обычный программист не питает особой любви ни к продажам, ни к рекламе. Но если Вы хотите, чтобы ваш проект был успешным с точки зрения бизнеса, без маркетинговой составляющей не обойтись. Самое простое, что Вы можете запланировать — поручить задачу продаж профессионалам. Если Вы нацелены на рынок США, то сейчас в Москве ищет работу Брайан, который успешно продавал программы Пентагону. Если рубите окно в Европу, то продвинуть продукт в Германии Вам поможет моя подруга Алина, редактор «Русской газеты», организатор русских дней и просто хороший человек. Наконец, если Вы хотите продавать свой продукт российским компаниям, где у нас всё на личном общении построено, то, Вам по пути с Ксенией — она профессионально организует для Вас обзвон Ваших потенциальных покупателей. Или просто отметьтесь здесь — я про Вас в какой-нибудь следующей статье напишу, или знакомому порекомендую.