К ИТ-проектировщикам относятся: консультанты бизнес-приложений, бизнес-эксперты/бизнес-аналитики.
Немаловажный момент: проектировщики не обязательно могут быть из бизнеса клиента. Это может быть группа только из представителей консалтинговой компании, которую нанял клиент, либо смешанная группа консалтинг плюс внутренние ресурсы, либо только внутренние ресурсы.
В общем случае задача проектировщика: собрать все требования бизнеса, т.е. понять какой ожидается результат, вникнуть в эти требования со 100% погружением в каждое, решить с бизнесом все вопросы и устранить разногласия; сформулировать все требования в таком виде, что они станут понятны для всех, еще раз все перепроверить с бизнесом и только тогда перейти к подготовке качественного технического задания на разработку. Все эти процессы могут потребовать очень много итераций. Даже если вопросом занимается признанный эксперт. И даже в этом случае есть вероятность получить “не тот результат, который нужен бизнесу”.
Задача программиста в общем случае: выполнить разработку по техническому заданию.
Под техническим заданием в данном случае предполагается документ, который содержит в себе следующую информацию: что требуется сделать, как должен выглядеть результат, какие технологии рекомендуется применять(необязательный раздел). В каждом проекте такой документ может назваться по разному, а также может состоять из нескольких документов(например, форма бизнес-запроса или пользовательская история и техническая спецификация).
Здесь не рассматривается вариант, когда программист сам себе проектировщик.
Итак, основные проблемы, с которыми сталкиваются проектировщики ИТ систем:
- Стейкхолдеры(держатели бизнес-процессов) не заинтересованы в ИТ-проекте
Стейкхолдеров обычно назначают во время проектной подготовки. Как правило выбирается ключевая фигура, которая владеет глубокими знаниями в части своих процессов. Не все согласны исполнять эту роль добровольно. Некоторые делают это потому, что “сказали делать”. В итоге получить какую-то информацию бизнес-эксперту весьма сложно. И даже если что-то получить удается, то процесс согласования решения может затянуться. Причиной такого поведение стейкхолдера могут быть: личное отношение к конкретному бизнес-аналитику, потому что заставили заниматься проектом против желания и т.д.
- Бизнес не понимает, что хочет получить в итоге от ИТ системы
“Сделай нам что бы было хорошо или не хуже чем сейчас” – типичный ответ бизнеса на вопрос, какой результат они хотят видеть в ИТ системе. Только тщательное обследование бизнес-процессов и многократное обсуждение деталей будущей реализации поможет в конечном счете получить желаемое.
- Бизнес вошел во вкус и генерирует бесконечное число изменений/улучшений решения в ИТ системе. Иногда все это остается на уровне тестов и не добирается до конечных пользователей
Очень частая проблема проектов. Во-первых нужно отделять критичные требования от фантазий. Во-вторых требуется обозначить конечную дату после которой все замечания не будут приниматься от бизнеса. Либо организовывать отдельные релизы, куда опять же будут попадать только критичные требования.
- бизнес-эксперту не хватает собственной компетенции в предметной области
Все знать невозможно и у компании могут быть процессы, с которыми эксперт никогда не сталкивался на предыдущих проектах. Тогда здесь на помощь приходят ключевые пользователи бизнес-процессов и другие коллеги.
- Не верно выбранная методология проектирования
Сейчас очень модно стало использовать Agile. Agilе прекрасно подходит для разработчиков, но не всегда пригоден для крупномасштабных ИТ-проектов. Вообще ведение проекта -это микс Waterfall, Agile и других методологий.
- Микроменеджмент
Обычно страдают от миркоменеджмента подчинённые руководителя, который сам когда-то был проектировщиком. Тотальное недоверие команде как профессионалам и перепроверка выполненной работы- в итоге время, которое можно было бы использовать на построение коммуникаций внутри проектной команды, потеряно; сроки проекта нарушены- клиент не доволен.
- нет налаженной коммуникации между участниками проекта
Любой проект это в первую очередь люди и если они совершенно между собой не взаимодействуют, то такой проект закроется очень быстро. Желательно в проектную группу подбирать людей, которые что называется понимают друг друга с полуслова либо учиться общаться.
Хоть в серьезных проектах программисты напрямую не работают с клиентом, но они все равно сталкиваются с определенными проблемами
- Недостаточно проработанное техническое задание бизнес-экспертом
По сути является источником большинства проблем. Непонимание требований клиента и аморфное описание, что должно получиться в итоге приводит к постоянным переделыванием/доделыванием решения. Случается и так, что концепция кардинально меняется и приходиться выполнять совершенно новую разработку, а предыдущую отправить в мусорное ведро.
- бесконечные требования бизнеса, которые не контролируются бизнес-экспертом(то есть принимается в реализацию все подряд)
Это приводит к тому, что разработчики “тонут” в одной задаче и не могут переключиться на следующие. В итоге сроки по другим задачам нарушаются-клиент не доволен, разработчики-перегружены и тоже не довольны.
- неверно поставленные приоритеты по задачам
Приоритеты по задачам должны исходить от бизнес-аналитиков. Как правило все заявляют, что каждая из их задач уровня “High”, т.е. должна быть выполнена здесь и сейчас. Тут возможен такой выход - индивидуально с каждым бизнес-аналитиком расставить реальные приоритеты.
- неверно определен уровень сложности задачи и сроки ее реализации
Плохо подготовленное техническое задание и нехватка опыта разработчика могут стать причиной неверного определения уровня сложности и в итоге привести к некорректной оценке сроков реализации. Хорошо если будет установлен средний приоритет простой задаче. А если нет? Очень часто в сроки реализации забывают заложить время на тестирование и обработку замечаний- его должно быть достаточно, что бы получить качественный продукт.
- коммуникации с проектной командой
Отдельно хотела бы подчеркнуть необходимость постоянно коммуницировать с коллегами и бизнес-экспертами. Времена, когда к программисту “на кривой козе не подъедешь” потому что “клиент-дурак и что он вообще может знать” проходят. Теперь требуется не только хорошо “кодить”, но и уметь общаться и объяснять почему так не получиться сделать, но можно по другому. И объяснять желательно не в поучительном тоне и непонятными словами, а доступным языком.
В данной статье я попыталась отразить то, с чем я сама и мои коллеги сталкиваются во время проектирования ИТ систем. Конечно каждый проект уникален и он может нести свои особенности, но со всеми вышеперечисленными пунктами приходиться сталкиваться в 97% из 100% на любом проекте.
Автор: Мария Абазьева, независимый эксперт SAP.