28 ноября 2017

Роли в команде разработки ПО

Часто Иногда при обсуждении недостатков приложений пользователи говорят, что разработчики поленились сделать хорошо. Но кто такие разработчики приложений? Давайте попробуем разобраться, какие роли есть в команде разработки.

А точно все они есть?

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

Проект

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

Команда программистов

Собственно, те люди, которые придумывают и реализовывают приложение. Они:

  • придумывают архитектуру приложения;
  • пишут код;
  • консультируют других, как писать код;
  • рецензируют код за другими;
  • пишут автоматические тесты (по крайней мере, их часть — модульные тесты);

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

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

Тестировщики

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

Тестировать приложения можно как вручную, так и при помощи автотестов (например, программно нажимать кнопки и проверять, какие экраны открываются).

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

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

Дизайнер

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

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

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

Заказчик или владелец продукта

Это человек, который определяет весь ход создания и развития продукта. Он принимает решение, что должно быть сделано, оценивает, соответствует ли реализация концепции продукта или нет. Например, программисты говорят ему: «Для реализации этой штуки нам потребуется два месяца. Или можем использовать кучу сторонних библиотек и сделать все за неделю, но тогда объем приложения увеличится на 30 Мб». Владелец продукта может сказать: «Еще 30 Мб? Это совершенно неприемлемо» или «У нас релиз через месяц, делаем как можно быстрее и запускаемся». И он же несет ответственность за направление развития продукта. Если вы читаете отзывы: «Зачем испортили такое хорошее приложение? Теперь оно вообще стало ни о чем», знайте, именно владелец продукта определил такую судьбу проекта.

Разница в названиях роли проистекает из типа компании. В продуктовой компании (которая разрабатывает свой внутренний продукт) назначается владелец продукта. При заказной разработке выделяется представитель заказчика, который будет взаимодействовать с разработчиками.

Может ли проект разработки обойтись без этого человека? Проект — может, а продукт (приложение) — нет. Кто-то все равно должен понимать, для чего это приложение разрабатывается и как оно должно существовать и развиваться в дальнейшем.

Руководитель проекта

Человек, который руководит всем этим безобразием всей этой командой. Отслеживает сроки выполнения задач. Оперативно реагирует, если начинаются проблемы с качеством. Мотивирует команду работать более эффективно («выбивает» премии, заказывает пиццу, и прочая, и прочая). Вместе с владельцем продукта принимает решения, когда возможны альтернативные варианты при выборе развития продукта в ходе разработки. Если проект очень большой и сложный (что все-таки для мобильных приложений редкость), то он может разбиваться на несколько подпроектов, и у них могут быть свои руководители, а в помощь руководителю проекта выделяется администратор проекта, который занимается большей частью «бумажной» работы: ведет протоколы совещаний (фиксирует принятые решения), рисует график прогресса проекта (например, «сгорание задач»).

По статистике, только малая часть проектов по разработке ПО завершается в срок с установленным уровнем качества и в рамках первоначального бюджета. Если что-то пошло не так, именно руководитель проекта в конечном счете принимает ответственность за то, чем придется жертвовать: выпустить продукт позднее, исправлять ошибки при помощи обновлений или выбить побольше денег (например, чтобы отдать часть разработки другой команде за отдельные деньги).

В небольших проектах с опытной командой программистов и тестировщиков можно обойтись и без явно выделенного руководителя проекта. Тогда обычно его роль исполняет ведущий программист — тимлид (калька с английского teamlead — лидер команды).

Заинтересованный топ-менеджер

В литературе по управлению проектами его обычно называют спонсором проекта. Для компании, разрабатывающей ПО на заказ, он не важен. И без него всем очевидно, что проект дает: это те деньги, за счет которых и живет компания. Но в компании, которая разрабатывает ПО внутри себя (это может быть и продуктовая компания, и компания, разрабатывающая приложения для своих внутренних потребностей), все может быть сложнее. Конкретное приложение может быть не столь важно для компании, размер и структура компании могут вносить свои коррективы (кто-то может решать свои личные задачи, например, по карьерному росту, за счет конкретного проекта). Поэтому становится очень важным, чтобы был топ-менеджер, который «болеет» за продукт и продвигает его. В этом случае при возникновении проблем команда разработки всегда может обратиться к нему, рассказать о проблемах и получить необходимые ресурсы. Типичный пример: премии за успешную работу. Если команда действительно старалась и выпустила приложение в срок с заданным качеством, руководитель проекта может обратиться к спонсору проекта для того, чтобы он инициировал выделение дополнительных средств на премию.

Заключение

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

Читайте также