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

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

Менеджер проекта может затруднять разработку ПО, но так ли это плохо на самом деле?

Цель продукта

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

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

Команда разработчиков

Зачастую команда разделяется на группы, которые занимаются своим направлением работы. Но это замедляет производство: коммуникация оставляет желать лучшего, скорость низкая, а постановка задач и анализ деятельности в целом усложняется. Роль менеджера – решить эту проблему.

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

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

Эксперимент или основательный продукт

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

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

Отсюда становится понятно, что менеджер, помимо вышеперечисленного, должен работать с целевой аудиторией. Он анализирует её потребности и ищет варианты для их удовлетворения. Конечно, не всегда он принимает верные решения.

Но вероятность провала можно уменьшить за счет MVP — наименее жизнеспособного ПО. Это позволяет экспериментировать с большим количеством идей и найти самую эффективную.

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

Внесение правок

Страшный сон любого разработчика – это внесение правок в готовый продукт. Ведь все итак работает идеально, включает в себя последние новшества и т.д. Именно этот этап является самым неприятным как для команды, так и для менеджера.

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

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

Налаживание взаимодействия и понимания

Основной проблемой оптимизации разработки ПО является тот факт, что разработчики не понимают требований клиента. Они не ставят себя на их место, «не переживают» их проблемы.

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

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

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

Итог

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

Профессиональный DevOps должен не просто контролировать и оптимизировать разработку ПО, но и понимать какие проблемы пользователя должен решать программный продукт. Свяжитесь с нами и мы поможем ориентировать ПО на проблемы клиента.