Сегодня мы решили поделиться с Вами опытом одной из команд, которая работает на крупном проекте по continuous development. Мы расскажем вам о том, как из умирающего проекта и разрозненной группы специалистов они стали одной из самых сильных команд в своей компании. Конечно, не во всех компаниях и не на всех проектах сработают те приемы и идеи, которые применила команда, но их кейс в очередной раз доказывает, что даже самые безнадежные проекты можно вытащить.

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

Проект был завершен, в терминах успеха или провала о нем достаточно сложно судить. Мы с нашими коллегами сошлись на том, что с точки зрения классификации Standish group, этот проект может с гордостью попасть в категорию Challenged, что, с учетом огромной стратегической важности, вполне можно считать неплохим результатом.

После завершения данного проекта, был заключен контракт на сопровождение. Однако тут началось самое интересное. Договор сопровождения, в понимании рассматриваемой компании, — это решение очень базовых и простых задач, а также периодические консультации пользователей. Но здесь все оказалось иначе. Заказчик поставил себе баг-трекинговую систему, сформировал собственную IT службу как первую линию работы с пользователями, и перевел систему в стадию развития, инициировав проект класса continuous development. Ежедневно на команду стали переводиться десятки задач, некоторые из которых требовали мгновенной реакции, так как тормозили важнейшие процессы заказчика.

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

  • Анализ потребностей пользователя;
  • Разработка варианта реализации;
  • Согласование варианта реализации с пользователем;
  • Разработка технического задания (или подробного описания задачи во внутренней баг-трекинговой системе компании);
  • Передача задачи на оценку программисту;
  • Согласование оценки с руководителем проекта со стороны заказчика;
  • Консультация программиста в ходе разработки;
  • Тестирование;
  • Переносе доработки на рабочую базу.

Работа программиста заключалась в оценке задач и их реализации на тестовых серверах. А если говорить о менеджере проекта, он занимался сбором всех собранных задач в единый отчет каждые 2 недели и согласованием финансовых вопросов с заказчиком, а также контролем недогруженности или перегруженности сотрудников задачами. Казалось бы, вполне отлаженная система работы, которая не должна давать никаких сбоев: у каждого свои обязанности, которые ложатся в единый процесс, и все необходимые работы покрываются командой. Но, как оказалось, такая “слишком” отлаженная система дала целый ряд сбоев, из-за которых проект начал просто умирать:

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

Это лишь те факторы, которые бросились нам в глаза с первого анализа проекта и со слов наших коллег. Если копнуть глубже, наверняка, можно найти еще очень много других. Конечно, можно бесконечно говорить о том, что, возможно, у сотрудников был низкий уровень квалификации, что они не обладали нужными компетенциями, что неумение аналитика договориться с пользователем — это не проблема программиста, что надо нормально заниматься менеджментом проекта и так далее и тому подобное. Читатель может предположить, где были допущены ошибки и как было бы работать правильно, и будет абсолютно прав. Но на такой подход к организации работ повлияло огромное количество внешних и внутренних факторов и особенностей проекта, очень комплексных причин, которые нельзя было не брать во внимание. Но все же этот кейс мы решили рассказать, как реальный пример перестройки работы команды в несколько приемов. Интересно, что очень многие идеи и подходы были взяты из семейства методологий Agile, хотя в литературе идут постоянные споры о том, насколько эти подходы применимы и целесообразны в тех или иных ситуациях. В данном конкретном случае эти подходы сработали. Итак, что же было предпринято:

  • Команда разделяется на 2: одни работают по небольшим задачам из огромного пула от всех пользователей, другие работают с аналитической службой заказчика на крупных задачах по развитию.
  • Менеджер проекта занимается финансовыми вопросами, но также четко распределяет задачи по лидерам двух выделенных команд.
  • Формирование связок аналитик-программист. Работа строится таким образом, что анализом потребности, формированием варианта реализации, общением с пользователем, разработкой и тестирование занимаются связки по 2 человека, работая рядом в течение практически всего дня. Разумеется, работа с другими членами команды была возможна, но в основном стала строиться именно в связках. Программист практически в обязательном порядке участвует в обсуждении бизнес-потребности, а аналитик следит за тем, какие объекты меняются в конфигурации для более качественного тестирования. Технические задания при это были заменены на use-case диаграммы, понятные как аналитикам и программистам, так и пользователям.
  • Переход на коммуникацию с пользователями по скайпу вместо баг-трекинговой системы и организация частых выездов команды к заказчику (и аналитиков, и программистов).
  • Быстрая обратная связь по каждой заявке и доставка минимального продукта, но готового к использованию, в кратчайшие сроки.
  • Постоянное отражение трудозатрат в задачах в разрезе 1-2 часов с комментариями для того, чтобы менеджеры проекта со стороны исполнителя и со стороны заказчика следили за ходом задачи в режиме реального времени и понимали по ней прогресс. Кроме того, совместив это с предыдущим пунктом, мы также даем возможность менеджеру проекта со стороны исполнителя остановить работы по заявке, если он считает, что дальнейшие доработки нецелесообразны. А пользователь при этом в любом случае имеет некий полезный для него продукт.

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

Похожие статьи