statue of liberty

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

Нужно очень хорошо понимать отличие этих проектов от остальных и особенно от проектов внедрения компьютерных приложений в бизнес-процессы организации.

Существует два риска, которые очень часто выливаются в проблемы:

1. те кто специализируется на разработке ПО, не замечает как ступают на территорию внедрения и проект начинает надуваться… как правило с летальным исходом;

2. те кто специализируются на внедрении и организационных проектах, без понимания сложности, начинают разработку и качество результатов начинает существенно падать — и это в лучшем случае;

Для тех кто занимается чистым внедрением или чистой разработкой — эти проблемы неведомы. Но это редкие счастливчики.

Уходим в детали…

Отличительные особенности

Для начала давайте разберем критерии, по которым мы можем отличить проект разработки компьютерных приложений:

1. результатом такого проекта является компьютерное приложение (web, windows, android, iOS …), модуль (функциональный блок) или какое-то существенное изменение (что такое «существенное изменение» — разберем ниже);

2. эти проекты требуют глубоких знаний архитектуры компьютерных приложений и соответствующего стека технологий, но при этом подразумевают минимальное взаимодействие с пользователями или сотрудниками задействованных в каких-либо бизнес-процессах.

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

Если в ходе проекта разработки, доля взаимодействия с людьми начинает возрастать, то такой проект рискует перерасти в проект внедрения, а это уже другая весовая категория сложности и рисков.

Существенные изменения

Отдельной подкатегорией можно выделить проекты, которые стоит запускать, когда речь заходить о группе изменений, объединенных одной целью, которые могут длиться продолжительное время и затрагивать несколько версий (релизов).

Если изменение или группа изменений помещается в один релиз — затевать проект не стоит.

Но если одно изменение, тянет за собой серию других изменений, вот тут уже стоит задуматься о запуске проекта, потому что:

1. Эти изменения нужно кому-то коорденировать, т.к. изменения могут вносить различные специалисты, и должен быть кто-то, кто будет в курсе и сможет коордентировать разных людей

2. Одно изменение может потянуть за собой изменения других механизмов системы, это вызывает различные риски, которые также нужно учитывать и быть к ними готовыми — лучше всего это делать через проектное управление

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

Например:

В системе управления задачами, нужно было расширить блок Участники. Добавить возможность выбора не только сотрудников, но и группы

— Начали с проработки интерфейса, оказалось что нужно менять подсистему доступа

— Начали менять подсистему доступа, поняли что нужно оставить старую на некоторое время, потому рядом создали новый механизм, без ломки старого

— Внесли изменения в интерфейс, подружили с новой моделью, отладили новый

— Теперь нужно удалить старый механизм

Все 4 пункта — растянулись на 5 месяцев и 3 версии разработки. Без координации — было бы на много дольше, а в результате могли бы просто потерять вектор цели и забыть про то что старый механизм нужно удалить.

Опасный момент

Очень опасной, но также и крайне распространенной является ситуация, когда заказчик просит разработать некую систему: учет финансов, работа менеджеров по продажам или что-то типа того.

Вроде бы с первого взгляда это обычный проект разработки. Нужно что-то разработать.

Но шансов на успех у этого проекта не много, т.к. очень скоро окажется что приложение готово, но заказчик почему то не доволен. Система не работает.

Причина в том, что внедрение — это отдельная область знаний. А проекты внедрения — это отдельная категория проектов.

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

Долгое время мне удавалось реализовывать различные ИТ-проекты, лишь краем затрагивая разработку. Это вызывало дикие проблемы, потому старался всегда разработчиков обходить стороной. Лучше внедрить типовой продукт типа 1С УПП 8, а после чего можно дорабатывать. И это вполне реально, хоть многие 1С-разработчики в это не очень то верят 🙂

Итого

Но за последний год меня угораздило мне повезло заниматься проектами внедрения, вплотную завязанным на проекты разработки. Это был крайне тяжелый год.

После чего выработались те определения, которые вы прочитали в начале статьи.

Наверное для разработчиков приложений — я не открыл ничего нового. Те кто сидят за стенкой из Интернет в далеке от конечных пользователей — занимаются только проектами разработки компьютерных приложений — все это понятно как ясень день.

Но вот те кто работают в отделах ИТ различных организаций, вот для них это все суровые «трудовыебудни».

Готов поспорить, что в большинстве организаций нет таких процессов:

1. управление проектами разработки

2. управление релизами

3. управление изменениями по релизам

Хоть практика ITIL и говорит что они нужны, но многие этими рекомендациями пренебрегают. Или попытались, но не получилось.

Мне чаще приходится иметь дело с проектами внедрения, но за этот год пришлось углубиться в тему разработки и поставить вышеперечисленные процессы на поток.

Что заметил?

1. проще стало прогнозировать ресурсы и затраты на развитие информационной системы

2. у разработчиков больше позитива в работе, когда закрываешь не просто изменение или релиз, а целый проект, который целенаправленно вели и коорденировали долгое время

3. особенно хорошо, когда проект закрывает сам разработчик. Это уже не мелкое изменение — это уже проект. Совсем другие ощущения.

4. ну и конечно же качество разработки — хвосты не теряются, серии изменений проходят точнее и с меньшими ошибками

А какой у вас опыт внедрения рекомендаций ITIL? И как вы определяется проект разработки компьютерных приложений?