От хвоста до головы Практика разработки средних и крупных программных проектов

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

Просматривая тот же job.ru, хочется воскликнуть вслед за Остапом: «Лед тронулся, господа присяжные заседатели, лед тронулся!» Наконец-то среди потока продавцов коробочных продуктов и администраторов — «мальчиков на всё» — все чаще появляются вакансии аналитиков и проектировщиков программного обеспечения. Это не может не радовать. Значит, несмотря на ограниченность и узкую специализацию рынка разработки в России, у нас все же есть надобность в людях, способных принимать решения, от которых зависит успех или неуспех того или иного программного продукта.
Несмотря на медленный рост потребности в собственном ПО, все же потребность эта есть, а попытки наших разработчиков выйти на международный уровень и закрепиться на рынке аутсорсинга¹ ставят перед фирмами-разработчиками требование перейти на методы корпоративной разработки, перестроить все системы на одну задачу — эффективную выдачу итогового продукта, повысить его качество одновременно с уменьшением сроков выпуска новых версий.
Работа на рынок сильно отличается от работы отделов автоматизации на внутрикорпоративные заказы. Рыночные продукты в силу своей специфики содержат в себе множество разнообразных функций (выгодно или не очень отличающих их от конкурентов), возможностей настраивать их различными способами для нужд пользователя, способность работать в разнообразных операционных системах и различном окружении. И для реализации всех этих возможностей и новшеств требуется время.

Главные проблемы разработки по со сроком реализации больше шести месяцев

Главная проблема любого проекта — его выполнение в срок и в полном объеме. На реализацию программы-максимум влияет огромное количество факторов. И чем дольше срок разработки, тем больше рисков² на пути к финишной черте. И раз фактор времени — один из важнейших, то часто проекты пытаются классифицировать на его основе. Например, в FAQ list of relcom. comp.software-eng проекты по срокам разработки делятся следующим образом: крупный — начиная от ста человеко-лет, средний — начиная от десяти-двадцати человеко-лет.
Лично мне удобнее делить проекты в «смешанном представлении», где оценочную роль играет время, но итоговая граница выставляется от возможности реализовать задачу одним человеком:

•  маленькие проекты (до шести человеко-месяцев);
•  средние проекты (до двух человеко-лет);

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

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

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

• разработчик посчитал, что на модуль у него уйдет три месяца работы «от рассвета до заката»;
•  менеджер проекта посчитал, что программисты «опять умножили на три», и оценил срок в один месяц работ;
•  начальник направления для улучшения показателей «округлил» до одной недели;
• секретарша босса решила порадовать шефа и доложила, что за день управятся;

 в итоге разработчиков «построили» за то, что шеф после обеда желал посмотреть «эту новую штучку, что мы уже продаем», но так и не нашел иконку запуска на своем столе.³

Использование современных алгоритмов управления
процессом разработки
А еще я знаю кучу страшных слов: uml, rose, iconix, две «мыслящие обезьяны» за клавиатурой (экстремальный программинг), MS Project и так далее…
Из эпоса перекуров

На Диком Западе не только штампуют металлических паровых пауков для нужд Голливуда, но еще и пытаются решить задачи коммерческой разработки программных продуктов с уменьшением объема финансовых и временных затрат с одновременным повышением процента успешно завершенных (и проданных) работ. Стандартом для проектирования объектных систем, объединяющим аналитику, проектирование, конструирование, документирование и др. этапы разработки, является UML (Unified Modeling Language) — унифицированный язык моделирования. Созданные с его помощью модели затем можно перенести в код конкретного языка разработки.
Наиболее развитым пакетом, включающим в себя поддержку UML и позволяющим вести на его основе полнофункциональную разработку с охватом всех особенностей построения, реализации, тестирования и поддержки программного продукта, является Rational Suite Enterprise от фирмы Rational Software.
UML используют и другие группы разработчиков, создавая и предлагая свои собственные методики. Можно отметить, что любая из методик в своей основе содержит решение главной проблемы — проблемы управления рисками и нацеленность разработки на результат — выпуск программного продукта. И не суть важно, от чего отталкиваются авторы — от анализа структур данных или предметной области, от проектирования или кодирования. Ваша задача при оценке методики заключается в проверке того, насколько предлагаемые методы ложатся на работу коллектива и насколько следование этим принципам уменьшит сумму рисков по выпуску программного комплекса.
Однако кроме самих методик выделения предметных областей, сущностей и объектов программирования, нельзя забывать о том, что разработка ПО не только работа программистов, но еще и контроль над всем этим. Для контроля используются как непрофильные программы (Excel), так и специально разработанные для этого.
Базовой системой ведения проекта считается (и используется той же Rational) Microsoft Project. Именно эту вещь я могу рекомендовать как инструмент, позволяющий решить вопросы прогнозирования сроков разработки, оценки объемов выполненных работ и отслеживания текущего положения в реализации поставленных задач. MS Project может использоваться и в небольших коллективах, и в крупных организациях (в серверном варианте). Фактически продукт является стандартом де-факто для систем управления проектами.
К следующей группе можно отнести собственные системы учета. Среди их достоинств — разработка под конкретный проект и определенные методы ведения работ фирмой, настроенность на требования именно этого менеджерского звена. Однако это является и слабой стороной подобного рода систем. Требования в изменении процесса разработки хоронят такого рода программы на корню, так как их перенастройка для новых реалий требует дополнительных финансовых и трудовых вложений.
Последним пунктом хочу отметить разнообразные системы учета рабочего времени «постфактум» («табелирование»). Табелирование работ обычно опирается на шаблонные формы (где отмечается, кто, сколько и что сделал или не сделал). Используется для контроля небольших этапов и разовых работ (включая установку ПО на площадке клиента). Удобно для последующей статистической обработки данных по выполненному проекту, но крайне неудобно для реального управления проектом.
Использование этих форм в технических отделах оправданно, однако попытка втиснуть разработку в эти «шаблоны» вызывает, по крайней мере, недоумение, хотя сталкиваюсь с подобного рода отчетностью довольно часто.

«Рыба» возможного проекта
Если вы видите эту доску уже десятый раз за полчаса, то вы не бредете вокруг бочки, просто это такой забор…
Из послезастольного эпоса

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