Сочетание специализации и личных качеств. Из кого состоит команда разработчиков?

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

Минимальный набор специалистов

В команде обязательно есть дизайнер UI (можно Ux/Ui), front-end программист и back-end программист, так же обязательно должен быть менеджер проекта, желательно тестировщики, так же будет большим плюсом если есть отдельные специалисты, которые будут заниматься исследованиями для всей команды разработки.

Дизайнер UX (user expirience, пользовательский опыт) – тот, кто занимается проработкой пользовательских сценариев. Продумывает, как именно пользователь будет работать с программным продуктом, какие функции обязательны, какие – нет, что добавить, убрать или улучшить. В общем, этот специалист работает с логикой продукта, он делает так, чтобы пользователю было удобно работать с программным продуктом. Работа такого специалиста очень схожа с работой аналитика, но ключевое отличие в том, что аналитик проводит максимально подробный анализ, в то время как непосредственно UX специалист может пожертвовать достоверностью исследования и гипотезы в пользу скорости принятия решения. И поменять что-то уже в процессе составления сценариев для пользователей.

Дизайнер UI (user interface, пользовательский интерфейс) – тот, кто работает с элементами интерфейса программного продукта. Дизайнер UI определяет цвета, расположение кнопок, как они Кработают и выглядят. Каким образом пользователь будет воспринимать интерфейс именно визуально – психологически.

Часто эти функции объединяются и их выполняет один специалист, ux/ui дизайнер.

Back-end программист пишет на языке программирования серверную часть программного продукта. Простым языком – он пишет саму суть работы программы. Например, я регистрируюсь на сайте, ввожу данные. Эти данные куда-то сохраняются, так вот, back-end говорит куда этим данным идти.

Front-end связывает макеты дизайнера с серверной частью программного продукта. Если проще – он говорит серверу как эти кнопки должны выглядеть и где располагаться, только на языке компьютера, а не в графическом редакторе у дизайнера.

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

Тестировщик – тот, кто тестирует программный продукт на предмет сбоев в работе, также команды таких специалистов тестируют продукты на предмет количественной нагруженности.

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

Графический дизайнер – работа такого специалиста заключается в отрисовке изображений для программного продукта, если таковой подразумевает иллюстрации и другую векторную графику.

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

Если взять ситуацию, в которой есть по одному специалисту из каждого направления – то на себя ответственность за организацию работы берёт менеджер проекта. При всей его ответственности, каждый из членов команды должен брать ответственность за свою часть работы в объёме равном 100%. В таком случае – менеджер проектов просто упаковывает результаты работы команды в различные отчёты и акты коммуникации для клиента, так сказать, представляет результаты ответственности всей команды перед клиентом.

Необходимые качества

Инструменты управления перечислять смысла нет, потому что вся проблема не в инструментах, в способности каждого члена команды договариваться между собой, а договариваться между собой это всегда совокупность следующих качеств (по моему опыту):

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

Такие вещи стопорят весь проект, это скрытая токсичность, которая провоцирует многих членов команды держать в себе много сомнений по поводу своего участия в проекте. С такими менеджерами и руководителями схема работы такая:

  1. Предупреждение.
  2. Следующий косяк – расставание.

Также важно чтобы младших управленцев курировал более опытный коллега.

Следующий навык – это базовая ответственность. Договорились созвониться в 9:00 – значит в 9:00.

Не в 9:20, не в 10:00. А в 9:00. Опаздываешь – предупреждаешь.

Способность менять свою точку зрения и признавать ошибочность и относительность мнений.

Человечное отношение к команде. В первую очередь это проявляется не в том, что человек говорит (хотя и это важно), а в том, как он ведёт себя каждый день. Опаздывает постоянно?

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

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

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

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