Должностные инструкции

Руководитель

Почему нужен

  1. Помогать другим добиться успеха. Помогать разработчикам развиваться в лидеров, обучать старших, ведущих и начинающих разработчиков.

  2. Своим примером показывать качественную и ответственную работу

  3. Поощерять рост и преемственность в организации

Процесс

Технологии и архитектура

Человеческие ресурсы

Инженер-программист (разработчик)

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

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

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

Стажер (intern)

Проходит базовую подготовку и обучение, решая задачи организации.

Разработка ПО

  1. Кодирование под руководством наставника

Начинающий (junior)

Требования для перехода на уровень

Присваивается по окончании испытательного срока.

Разработка ПО

  1. Самостоятельное решение задач кодирования

  2. Написание модульных тестов

Начинающий+ (junior+)

Требования для перехода на уровень:

  1. Сдача теоретического экзамена по архитектуре (1 уровень, разделы 1-4 и 7-8)

  2. Рекомендация старшего разработчика или руководителя

  3. Рекомендация технолога (менеджера продукта)

Ведущий (middle)

Требования для перехода на уровень

  1. Ревизия кода старшим разработчиком или руководителем на соответствие требованиям качества.

  2. Рекомендация технолога (менеджера продукта)

  3. Не менее 50% необходимых навыков должности Инженер-программист на уровне «средний»

Разработка ПО

Диагностика и устранение ключевых проблем в ПО

Наставничество

Старший (senior)

Старший разработчик это не «сверхскоростной» ведущий разработчик. На данном уровне ценность представляет не скорость кодирования задачи, а ваша способность разбираться в решаемых проблемах. Решая задачу, задавая вопросы, вы формулируете проблему для себя и своей команды. А наибольшую ценность вы приносите своей способностью переформулировать проблемы.

Требования для перехода на уровень

Почему нужен

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

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

  3. Понимать бизнес-цели продукта, объяснять их на понятном разработчикам языке

  4. Передавать опыт младшим разработчикам

Разработка ПО

Диагностика и устранение ключевых проблем в ПО

Наставничество

Вопросы

Как старшему разработчику улучшить процесс разработки? Какие узкие места в разработке имеются?

  1. Качество кода. Что выгоднее в «общем зачете»: отдать в тестирование плохой код или потратить время на написание юнит-теста? Протестировать код самому или создать движок для тестирования и помочь развиваться QA-Инженеру?

  2. Делегирование. Что выгоднее: кодировать самому или делегировать кодирование, а после провести ревизию кода? Развиваться самому или развивать команду? Выгорать на работе или запросить помощника у руководства?

Менеджер продукта

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

Стажер (intern)

Вы выполняете больше административную функцию. Работа под руководством наставника.

Начинающий (junior)

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

Обязанности

Документация

  1. Ведение дорожной карты продукта

  2. Ведение базы знаний продукта

  3. Составление протоколов собраний с командой и заинтересованными лицами, телефонных разговоров

Коммуникация

  1. Встречи с командой

  2. Коммуникация со связанными командами

  3. Коммуникация с заинтересованными лицами: своевременное сообщение проблем, планов, рисков. Заинтересованные лица должны знать, что происходит.

Ведущий (middle)

Для перехода на данный уровень требуется создать «минимально жизнеспособный продукт (MVP)» совместно с наставником или руководителем бизнес-подразделения.

Документация

  1. Ведение дорожной карты продукта

  2. Ведение базы знаний продукта

  3. Составление протоколов собраний с командой и заинтересованными лицами, телефонных разговоров

Коммуникация

  1. Встречи с командой

  2. Коммуникация со связанными командами

  3. Коммуникация с заинтересованными лицами: своевременное сообщение проблем, планов, рисков. Заинтересованные лица должны знать, что происходит.

Принятие решений

  1. Формулирование гипотез совместно с владельцем продукта

  2. Тестирование гипотез с привлечением экономистов и аналитиков данных

  3. Принятие решений на основе статистической проверки гипотез

Старший (senior)

Документация

  1. Ведение дорожной карты продукта

  2. Ведение базы знаний продукта

  3. Составление протоколов собраний с командой и заинтересованными лицами, телефонных разговоров

Коммуникация

  1. Встречи с командой

  2. Коммуникация со связанными командами

  3. Коммуникация с заинтересованными лицами: своевременное сообщение проблем, планов, рисков. Заинтересованные лица должны знать, что происходит.

Принятие решений

  1. Формулирование гипотез совместно с владельцем продукта

  2. Тестирование гипотез с привлечением экономистов и аналитиков данных

  3. Принятие решений на основе статистической проверки гипотез

  4. Формулирование метрик продукта

  5. Приоритизация работ .Выбораете наиболее эффективные по соотношению затрат/эффекта инициативы.

  6. Использование данные для принятия решений, оценки инициатив используя собственные навыки (python, excel) или привлекая аналитиков данных.

  7. Формулируете видение продукта и дорожную карту для его достижения. Владеете «сегментом» дорожной карты продукта.

Вопросы

Как менеджеру продукта улучшить процесс разработки? Какие узкие места в разработке имеются?

  1. Качество кода. Продукт выпускается «сырой». Что лучше: тестировать самому, запросить новых тестировщиков у руководства, или попросить программиста научить тестировщика автоматизации?

Оценка результатов работы менеджера продукта

Оценку результатов работы менеджера продукта можно разбить на 3 направления:

  1. Финансовое направление: Оценка влияния инициатив (реализованного функционала продукта и/или орг. иницитив без участия команды инженеров) на метрики продукта. Оценивается способность менеджера продукта переводить аналитику продукта (анализ данных) в эффективные инициативы по улучшению метрик.

  2. Клиентское направление: отношение потребителей к продукту: довольны клиенты реализованным продуктом, привлечение и сохранение пользователей продукта

  3. Управление и коммуникация: способность эффективно управлять командой разработки, сотрудничать с заинтересованными сторонами. Способность улучшать командную работу, налаживать эффективную коммуникацию.

Принятие решений

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

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

У вас нет такой цели — не совершать ошибки. Но если вы все же добились этого и в одном прекрасном проекте не совершили ни одной ошибки. Хорошо это или плохо? Да, вы не потратили время на исправление ошибок. Но сколько лишнего времени вы потратили на такой перфекционизм? Возможно что стоимость исправления большинства ошибок была бы не больше одного дня, а сколько времени потратили вы, чтобы их избежать?

Анализ данных

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

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

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

Коммуникация

Менеджер продукта должен иметь развитые навыки коммуникации. Команда инженеров, заинтересованные лица и CEO компании желают видеть совершенно разную перспективу.

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

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

Менеджер продукта никогда не будет иметь достаточной квалификации для принятия всех решений. Задача менеджера продукта — предоставление необходимой для принятия решений информации инженерам и аналитикам.

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

Обучение и мотивация

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

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

Должен ли менеджер продукта уметь программировать?

Нет, но понимать программный интерфейс приложений и структуру данных нужно.

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

Должен ли менеджер продукта понимать психологию?

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

Аналитик данных (data scientist)

Задача аналитика - построение математических моделей, статистически отражающих ведение бизнеса и поведение клиентов.

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

QA-Инженер

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

Должностные обязанности QA-Инженера

Основное направление развития QA-Инженера — смещение работ к проектированию продукта.

Стажер (intern)

Работа под руководством наставника.

Начинающий (junior)

Обязанности:

  1. Ручное регрессионное тестирование

Ведущий (middle)

Обязанности:

  1. Формулирование критериев приемки

  2. Формулирование сценариев тестирования

  3. Написание автоматизированных критериев приемки с использованием визуальных средств (ui.vision)

Старший (senior)

На данном уровне QA-Инженер разрабатывает независимые проверочные реализации алгоритмов на языке программирования.

Обязанности:

  1. Автоматизированные тесты на языке программирование

  2. Руководство профильной командой

Вопросы

Как QA-инженера улучшить процесс разработки? Какие узкие места в разработке имеются?

  1. Качество кода. Что лучше: тестировать самому, или сформулировать критерии приемки, план тестирования и делегировать эту работу?

Оценка результатов работы QA-Инженера

  1. Статистка ошибок — количество тикетов/ошибок после выкладки функционала. Количество регрессионных ошибок (внесенных в старый функционал при разработке нового функционала)

  2. Полнота тестовых сценариев — реализация проверки максимально возможных вариантов исполнения программы с минимальным затратами

  3. Обучение/наставничество — простота подключения новых тестировщиков, возможность тестирования по готовым сценариям.

Заинтересованные лица

Заинтересованные лица (stakeholders) — бизнес и пользователи — участвуют в наполнении бизнес-слоя базы знаний проекта с целью максимального учета их интересов.