Проекты разработки компьютерных приложений. Особенности

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

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

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

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. ну и конечно же качество разработки — хвосты не теряются, серии изменений проходят точнее и с меньшими ошибками

5. на сколько удалось понять, в SCRUM — аналогом проекта является «запрос» или «заказ», который может поступить от «Заказчика», и который затем нужно разбить на задачи, которые могут закрываться в разных релизах.

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