5 главных рисков при заказной разработке ПО
Мы продолжаем цикл статей, в которых рассматриваем методологические вопросы создания программного обеспечения. Методология — это, прежде всего, владение стратегией через использование тех или иных принципов разработки. Знание принципов позволяет — сделать работу более сознательной, предсказуемой и менее подверженной рискам. Управлению последними и посвящена статья.
В её основе лежат главы из книги «Вальсируя с Медведями: управление рисками в проектах по разработке программного обеспечения» за авторством Тома ДеМарко и Тимоти Листера, которую мы можем смело рекомендовать каждому программисту и менеджеру в сфере создания ПО. В книге нет жесткого фокуса на гибкой методологии разработки, однако авторы постоянно обращаются к Agile.
Можно долго рассуждать на тему рисков и при желании назвать несколько десятков, но самыми распространенными и опасными из них являются только пять:
- внутренние сложности календарного планирования;
- увеличение требований со стороны заказчика в ходе реализации проекта;
- текучка кадров;
- нарушение спецификаций;
- низкая производительность.
И только пятый по счету риск зависит непосредственно от разработчиков. На оставшиеся четыре оказывают влияние либо внешние факторы, либо работа менеджера проекта. Вообще от квалификации, мотивации и работоспособности программистов зависит далеко не все. При создании ПО руководитель должен адекватно просчитывать риски и управлять ими. Такая деятельность не гарантирует на 100% успешного завершения проекта, но дает некоторый резерв в случае форс-мажорных ситуаций.
Внутренние сложности календарного планирования
Довольно часто при составлении планов менеджеры руководствуются или пожеланиями заказчика, или чрезмерно оптимистичными оценками возможностей подчиненных, т.е. выдают желаемое за действительное. Результат — существенное расхождение в планируемых и реальных сроках реализации проекта, которое иногда достигает 50–80%. В таком случае проблемы во взаимоотношениях с заказчиком и с перерасходом ресурсов неизбежны.
А всех собак по поводу срыва сроков чаще всего вешают на программистов, хотя данная ошибка происходит по вине руководства. Ведь если объем работы занижен на 80%, то абсурдно требовать разработку практически с двойной скоростью. Иногда встречается и обратная ситуация: срок реализации завышен. В таком случае велика вероятность потерять клиента уже на этапе проектирования, ведь найдутся кандидаты, готовые сделать быстрее и дешевле.
Для снижения риска несоблюдения графика в методологии гибкой разработки необходимо закладывать некоторый резерв времени на случай ошибок планирования и возникновения непредвиденных обстоятельств, а также максимально привлекать программистов к оценке сроков.
Увеличение требований со стороны заказчика в ходе реализации проекта
Требования заказчиков к конечному продукту часто меняются по ходу дела, особенно это касается крупных задач. Это означает, что если вы договорились о поставке через 10 месяцев продукта Х, наверняка заказчику нужен будет продукт не Х, а Х-штрих. Это влечет дополнительные трудозатраты.
Сколько же дополнений разумно планировать? Адекватной является оценка в 1% ожидаемых изменений в месяц, т.е. для проекта длиной в год следует заложить примерно 12% времени на удовлетворение новых пожеланий заказчика.
Agile предполагает регулярное обсуждение с клиентом смены сроков и функционала на всех этапах сотрудничества. Вместо игнорирования или подавления изменений со стороны заказчика используется расстановка приоритетов, позволяющая рационально выполнить необходимые нововведения по ходу дела.
Текучка кадров
Кажется, что люди всегда уходят в самый неподходящий момент, и это неизбежно. Само собой, потеря опытного сотрудника, который эффективно взаимодействует с членами команды, знает специфику конкретного проекта и организации в целом, и замена его на нового человека влечет за собой затраты времени.
Для снижения данного риска в Agile необходимо сделать две вещи.
- Увеличить объем целевых коммуникаций между членами команды, чтобы потеря любого из сотрудников не оказалась критичной. Разработка не должна быть «замкнута» на конкретной личности.
- Создать для сотрудников комфортную среду, чтобы не было желания ее покинуть. Если работа в компании является делом материально выгодным, интересным и захватывающим, то вероятность увольнений снижается.
Нарушение спецификаций
Риски этого пункта несколько выделяются из списка: они или сбываются и приводят к краху, или не сбываются и никоим образом на проект не влияют. Опасность состоит в том, что заключенное соглашение часто несет в себе скрытые конфликты и по-настоящему не устраивает ни одну из сторон. А в ходе разработки и внедрения ПО эти моменты всплывают, и начинаются проблемы. Если прийти к консенсусу не удается, проект часто сворачивается, а настоящая причина этого — недостаточное согласование. Доля прекращенных таким образом проектов оценивается примерно в 15%.
Для снижения опасности нарушения спецификаций в гибкой методологии используют посредника, который видит и разрешает на раннем этапе все имеющиеся противоречия, помогает сторонам достигнуть согласия по всем вопросам. Особенно это касается договоренностей по потокам данных.
Низкая производительность
Производительность отдельного человека и коллектива в целом — вещь динамическая, нелинейная, и ее довольно трудно оценить. Наибольшее значение имеет следствие закона Паркинсона: команда разработчиков активизируется только к концу срока сдачи проекта, а в остальное время работает в полсилы.
В гибкой методологии задача разбивается на короткие этапы, постоянно вызывая ощущение скорого дедлайна.
ДеМарко и Листер приводят интересный расчет: при планируемом времени на завершение проекта в 26 месяцев, вероятность уложиться в срок — всего 4%. С 75% вероятностью работа завершится к 38-му месяцу, а в 15% случаев проект вообще не будет сдан. Эта оценка является довольно обескураживающей и заставляет задуматься, как можно снизить риски и сократить сроки реализации проектов.
Как видно, авторы «Вальсируя с Медведями» считают гибкую методологию разработки довольно продуктивным средством снижения рисков. Однако даже в этом случае необходим пристальный контроль за всеми возможными трудностями.
