Команда IT-продукта (ч1). Из кого она состоит?

Приветствую в это нелегкое время. Я продолжаю цикл статей для предпринимателей и несколько следующих хочу посвятить краеугольному камню любого IT проекта или продукта - команде.

В отличие от многих сфер бизнеса, где “чем главнее, тем круче”, IT больше похож на медицину. Линейный разработчик, как и практикующий врач в частной клинике, может получать огромные деньги, значительно выше менеджмента.

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

За последние годы доля крутых специалистов на рынке сильно уменьшилась. Еще 10 лет назад разработчиками и аналитиками становились только получившие профильное техническое образование и имеющие так называемую “базу”. Но с развитием онлайн-курсов и снижением порога входа в профессию за счет появления новых технологий на рынке с каждым днем становится все больше новичков, не имеющих опыта коммерческой разработки, которые хотят космические зарплаты.

Все эти аспекты необходимо будет учитывать как при формировании своей команды, так и при работе со сторонней компанией.

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

Во главе продукта стоит Product manager или Product owner. Разница есть, но для нас она не существенная. Он работает с рынком, общается с пользователями и инвесторами, определяет вектор развития продукта, генерирует гипотезы и пользовательские истории, приоритезирует их и много другое. Если упростить, он на основе данных решает, какие потребности и в каком порядке необходимо закрыть.

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

Marketing team отвечает за позиционирование продукта и привлечение пользователей. Support team - команда клиентской поддержки, отвечающая на вопросы пользователей. На старте продукта вам будет достаточно одного маркетолога, а клиентской поддержкой могут заниматься продакт и проджект менеджеры, получая при этом очень ценную обратную связь. Поэтому я не буду разбирать эти направления и сконцентрируюсь на команде разработки.

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

Проектный менеджер отвечает за реализацию определенного функционала в рамках согласованных сроков и бюджета.

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

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

Бизнес-аналитики составляют бОльшую часть всех аналитиков в рамках стартапов, поэтому разберу именно их. Компетенции БА я разделяю на две больших области: продуктовая аналитика и формирование требований.

О продуктовой аналитике, которую необходимо провести до начала реализации, я писал в прошлых двух статьях: Есть идея IT-продукта. Что делать дальше? и Зачем нужен MVP. Помимо описанных там анализа ЦА, конкурентов и рынка, проведения проблемных и решенческих интервью, арсенал продуктового аналитика включает в себя большой спектр инструментов, позволяющих находить точки роста. Итогом этой части работы становятся пользовательские истории - формулировки вида “как покупатель, я хочу фильтровать товары, чтобы выбирать только среди релевантных” с различными дополнениями и ограничениями вроде названий фильтров или максимально рентабельной стоимости разработки. Это своего рода условия задачи.

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

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

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

Лиды определяют “правила игры” в своем отделе: какие инструменты, подходы, технологии и тд будут использоваться. Если каждый сотрудник в направлении будет делать по-своему, об эффективности можно забыть.

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

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

Работу дизайнера можно условно разделить на 3 части:

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

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

Техлидами становятся очень опытные разработчики, имеющие развитые коммуникативные навыки. Фактически это второй ПМ, только с другими хард-скилами.

Перед тем как переходить к зонам ответственности разработки, необходимо на элементарном уровне понять принцип работы веб или мобильного приложения.

Клиент - веб или мобильное приложение - эта та часть, которую видит пользователь. Например, пользователь интернет-магазина, находясь в разделе кроссовки, выбрал в фильтре по бренду Nike. Тогда клиент посылает запрос на сервер, говоря “пришли мне все кроссовки Nike”. Сервер получает и обрабатывает этот запрос: команда проекта заранее определила, что пользователям должны показывать только товары, которые есть в наличии. Сервер обращается к базе данных, которая формально может быть как на этом, так и на другом сервере: “пришли мне все кроссовки с брендом Nike, которые есть в наличии”. В ответ сервер получает список товаров, но, если отправить все сразу, страница у пользователя может грузиться очень долго. Поэтому на сервере товары дробятся на страницы, а на клиент приходит ответ: “Всего нашлось 147 товаров, я разделил их на 8 страниц по 20 товаров, держи первые 20”. В итоге у пользователя отображаются первые 20 кроссовок Nike.

Большое приложение может иметь множество серверов и баз данных, но описанные выше принципы будут неизменны.

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

В процессе работы он больше всего взаимодействует с дизайнерами по вопросу макетов и с серверными разработчиками(back-end developers) по обмену данными.

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

Мобильных разработчиков по используемым технологиям можно разделить на нативных и кроссплатформенных. Первые пишут приложения для конкретной ОС(iOS или Android), вторые сразу под обе.

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

Бэки отвечают за серверную часть приложения и базу данных. Они пишут код, обрабатывающий запросы от фронта, делают запросы к базе, настраивают серверы и тд.

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

Итоговая цель любого тестировщика - обеспечить высокое качество продукта.

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

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

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

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

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