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

Важные книги по Скрам

• Джефф Сазерленд: Революционный метод управления проектами.
• Эрик Рис: Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели
• Роберт Фитцпатрик: Спроси маму: Как общаться с клиентами и подтвердить правоту своей бизнес-идеи, если все кругом врут

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

Важные книги не про Скрам

Скрам не решит всех ваших проблем, полагаясь только на этот метод, можно потерпеть фиаско. Книги, которые помогут в управлении любой командой:

• Максим Батырев: 45 татуировок менеджера.
• Михаил Хазин, Сергей Щеглов: Лестница в небо. Диалоги о власти, карьере и мировой элите.
• Роберт Грин: 48 законов власти.

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

Особенности Скрам

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

Первое, на что следует обратить внимание, есть ли у вас обратная связь с конечными пользователями и вносите ли вы изменения в создаваемый продукт с учетом этой информации. Если нет, то будьте уверены, у вас не Скрам.

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

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

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

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

Насколько точно надо придерживаться правил Скрам?

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

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

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

Не забывайте о том, что многое, что является вполне естественным и не требующим объяснения для американского читателя, не является таковым для российского. Многие практики, эффективные на западе, совершенно не работают у нас. Это может быть обусловлено, помимо различий в культуре и законодательстве, например, довольно большой властью американского работодателя над работником. Работодатель в США может очень быстро уволить сотрудника, а увольнение там может означать потерю страховки, способности платить по счетам, потери собственности, даже нищите. У нас же увольнение иногда ничего не меняет, да и уволить иногда не удается. Отсюда и разное отношение к работе, компании, начальнику, конкуренции, саморазвитию, корпоративной культуре. Отсюда возникают разное понимание одного и того же текста, разное применение одних и тех же методов.

Доски со стикерами

Не могу пройти мимо этого явления. Если команда находится в одном офисе, может быть это и неплохое решение, поскольку позволяет общаться всем членам команды лицом к лицу. Кроме того, митинги у доски проходят стоя, что должно помогать избегать длинных собраний. Однако, информация, написанная на стикерах от руки плохо читаема и непонятна новым членам команды. К стикеру нельзя приаттачить файл, добавить описание или ссылку. Непонятно на кого назначена та или иная задача. Да, на стикерах можно указать идентификаторы тикетов Jira, но это не решает проблему. Часто можно заметить, что возле доски собирается более 20 человек, при том, что классическая Скрам команда должна иметь в своем составе не более 9 человек. Во время проведения таких собраний образуются небольшие группы сотрудников по интересам или специализации, которые начинают независимые совещания, мешая друг другу. И такие совещания, как показывает практика, не проходят быстро, несмотря на то, что проводятся на ногах. На доске часто можно увидеть вместо трех — пяти столбцов целый десяток и больше. Но самое неприятное в наличии доски — это отсутствие единого источника правды, т.е. существуют одновременно как доска так и dashboard в Jira. Пора прекратить пользоваться досками. Ниже я приведу описание митинга, который подойдет как для офисной, так и для распределенной команд.

Роли членов команды

Роли членов команды могут быть, например:

• Product Owner
• Scrum Master
• Business Analyst
• Software Architect
• Software Analyst
• UI / UX / Web Designer
• Html Developer
• Front End Developer
• Back End Developer
• Full Stack Developer
• DB Developer
• DBA
• Quality Assurance
• DevOps Engineer
• и т.д.

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

Вариант команды в реальных условиях

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

• Product owner (PO), он же Business Analyst. Концентрируется на продукте, взаимодействует с заказчиками и инвесторами, знает бизнес-процессы. Определяет приоритет реализации той или иной фичи. Отвечает за финансы, переводит деньги (зарплату) членам команды в соответствии с выставленными счетами за период.
• Scrum master (SM), частично Business Analyst, Software Analyst. Концентрируется на команде, решает организационные вопросы, назначает встречи, обеспечивает соблюдение ритуалов Скрам, формирует бэклог, создает стори и назначает исполнителей, утверждает (approves) затраченное время членов команды, утверждает счета на оплату услуг каждого из членов команды.
• Software Architect (SA), он же Team Leader для разработчиков, DevOps, DBA. Администрирует серверы, среды, GitLab, Jira, Confluence, Jenkins, корпоративную почту, Zoom, VPN, выделяет или блокирует доступы.
• Web Designer (дизайнер) на неполный рабочий день. Дизайн интерфейса с использованием Photoshop, Zeplin, Invision, Figma.
• HTML Developer (верстальщик) на неполный рабочий день. Несмотря на то, что знание HTML и CSS является обязательным для Front End Developer / Full Stack Developer, это не всегда обеспечивает высокое качество верстки. По этой причине в команду приглашаются профессиональные верстальщики, которые трансформируют дизайн в шаблоны, применяемые в дальнейшей разработке фронта.
• Senior Full Stack Developer (разработчик) на полный рабочий день, он же DB Developer. Из-за ограниченного бюджета не всегда есть возможность нанять фронтиста и бэкенд разработчика. На начальном этапе и для запуска MVP будет вполне достаточно одного Full Stack Developer-а. Кроме того, скорость команды на начальном этапе может быть такой, что одного разработчика вполне будет достаточно. В дальнейшем можно увеличивать команду, нанимая специалистов на разные роли.
• QA на неполный рабочий день. На начальном этапе можно обходиться без привлечения профессиональных тестировщиков, но по мере разрастания системы они становятся просто обязательными.

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

Процесс

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

Колонки в проекте в Jira (вариант):

To do  |  In Progress  |  Code review  |  QA  |  Demo ready  |  Done

Предположим, что члены команды живут в разных часовых поясах от Екатеринбурга до Чикаго. Оптимальным временем для митинга может быть, например 15:00. SM запускает трансляцию своего экрана через Zoom, открывает dashboard проекта в Jira. Затем SM включает фильтр тикетов како-го либо из членов команды, при этом становятся видны тикеты только этого члена команды.

Этот сотрудник кратко рассказывает о своих тикетах в колонке In Progress и о трудностях, с которыми он сталкивается, о том, что его блокирует. Далее SM переключает фильтр на другого сотрудника. SM следит за тем, чтобы выступления членов команды были короткими. В моем случае я настоял на отдельном тикете для списания времени, потраченного на митинги, и спустя 2 недели SM сильно сократил длительность митингов, посчитав их стоимость. Если у кого-либо возникают вопросы, требующие дополнительного обсуждения, то они обсуждаются на отдельном митинге, время которого определяет SM. Создание любого митинга сопровождается рассылкой приглашения в персональный календарь каждому из участников. Использование календаря избавляет участников от необходимости пересчета времени проведения митинга в локальное время. Выявив и обсудив все проблемы, возникшие на данный момент, SM принимает меры по их устранению, координируя действия всех членов команды.

Разработка ведется поэтапно спринтами по 1 или 2 недели. Результатом каждого спринта является промежуточная версия системы с некоторым новым функционалом (фичами). SM создает, запускает и закрывает спринты.

SA конфигурирует билд и деплой на тестовый стенд из какой-либо ветки Git, которую можно условно назвать dev. Ветка dev заблокирована для прямых коммитов, возможен только Merge request (MR). Разработчик делает MR, если уверен, что качество и завершенность фичи достаточны для использования конечными пользователями. Недоделанные фичи в dev не попадают, MR не создается.

PO и SM согласуют требования, собирают все необходимые материалы в Confluence, создают спецификацию. Гибкие методы отодвигают документацию на второй план. Я сталкивался как с системами, где нет никакой документации, так и с системами, где ее настолько много, что в этом океане информации ничего невозможно найти. Ситуация с обилием документации усугубляется примитивностью поискового движка Confluence. Оптимальным решением является компактная спецификация. Она представляет собою страницу в Confluence, в которой есть схематичное изображение интерфейса (mockup) с отметками и выносками. Под изображением находится описание функционала и поведения каждого элемента, отмеченного на схеме. В тексте есть ссылки на релизы и тикеты в Jira. В нижней части страницы идет обсуждение в комментариях.

Перед началом спринта SA формирует бэклог, создает новые стори и добавляет их в будущий спринт, назначает разработчиков на каждую стори. Разработчики разбивают стори на подзадачи, определяют Estimate (приблизительное прогнозируемое время разработки) в часах и минутах. Полученное суммарное время подзадач определяет количество Story points из расчета 1 Story point = 6 часов. Далее тимлид распределяет стори по разработчикам исходя из расчета 8-12 Story points на разработчика на спринт. SM запускает спринт.

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

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

Разработчик создает ветку в Git по имени тикета стори, например MVP-123. По завершении каждой подзадачи разработчик записывает в Jira фактическое затраченное время на каждую из подзадач. В качестве TimeSheet рекомендую Tempo. По окончании отчетного периода (2 недели или 1 месяц), разработчик запрашивает утверждение отработанных часов у SM, формирует счет на оплату, отправляет его SM. Когда все задачи в стори готовы, разработчик перемещает все тикеты (стори и подзадачи) в столбец Code review. При этом разработчик создает MR своей ветки в dev, копирует ссылку на него и помещает в комментарии к тикету стори, назначает тикет на ревьювера (сеньора или тимлида). Изменение исполнителя сопровождается его оповещением по электронной почте.

Когда тимлид заметил новые тикеты в Code review он изучает MR и, если находит недостатки, пишет их в комментариях в GitLab, перемещает тикеты назад в столбец In Progress. Разработчик дорабатывает код, добавляет комментарий в GitLab (или в другой системе), нажимает Resolve discussion в комментариях, переносит тикеты в Code review. Особенностью GitLab является невозможность добавления нескольких ревьюверов. Это часто бывает необходимым, если изменения затрагивают, например, как фронт, бек, так и базу данных. В BitBucket такая возможность есть.

Иногда возникают ситуации, когда принимаются несколько MR и они конфликтуют. Разрешать конфликт должен разработчик, создавший MR последним. Он объединяет ветку dev со своей текущей и устраняет конфликты, делает дополнительный коммит.

В некоторых ситуациях, многочисленные MR, даже в случае удачного слияния, приводят к невозможности сборки или невыполнимости части unit тестов. Иногда это становится известно после того, как одна из сред перестала работать, что блокирует, например, QA. То есть тимлид может провести ревью и принять MR, но это не гарантирует успешность сборки или выполнения unit тестов. Для решения этой проблемы, например, в GitLab есть возможность настройки Development Pipeline. По сути это автоматическая сборка и тестирование коммита, который указан в MR. Код ревью выполняется только после успешного выполнения Development Pipeline. Если Development Pipeline “падает” с ошибкой, разработчик, сделавший MR, устраняет ошибку и делает дополнительный коммит.

Тимлид принимает код и принимает MR, при этом происходит автоматическая сборка и деплой на тестовый сервер. Тимлид переносит код в столбец QA.

QA приступает к тестированию новых изменений в соответствии со спецификацией. QA создает программы ручного тестирования. В случае неудачного тестирования, тикет переводится в столбец In Progress — возвращается на доработку, либо создается баг-тикет в Jira, который SM назначает на какого-либо из разработчиков. После того, как тестирование завершено успешно, тикеты переводятся в Demo ready и, впоследствии, фича демонстрируется на еженедельном Demo митинге. Если фича принимается, тикет переводится в Done.

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

PO и SM определяют набор фич (стори), которые попадут в тот или иной релиз, планируют дату релиза. Перед релизом QA осуществляют регрессионное тестирование. В момент релиза создается специальная ветка в Git и замораживается для изменений. Изменения релизов возможны в исключительных случаях и производятся через бэкпорты. Бэкпорт — специальный процесс внесения изменений в релизные ветки. В некоторых компаниях для бэкпортов создаются специальные команды.

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

Что необходимо для работы (вариант)

• Пространство Slack
• Корпоративная почта в домене компании / стартапа (желательно, но не обязательно). Почта может быть настроена таким образом, что все письма будут перенаправляться на личные почтовые ящики членов команды.
• Zoom
• Jira и Confluence, размещаемые либо на собственных серверах, либо облачных.
• Серверы dev, test, prod сред как собственные так и арендуемые, как физические, так и виртуальные.
• Система контроля версий, например GitLab или BitBucket.
• Jenkins или Bamboo, или какая-либо еще система автоматической сборки и деплоя.
• VPN для доступа к средам и каким-либо серверам.

По возможности Slack, Jira, Confluence, Gitlab (или Bitbucket), Jenkins (или Bamboo) должны быть интегрированы друг с другом.

Учет времени

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

Хороший разработчик Self motivated (самомотивирован), стремится сделать больше в единицу времени, опережая estimate сроки, повышать свой авторитет, увеличивать шансы стать сеньором, тимлидом, иногда шансы на получение опциона. Он активен, генерирует идеи, непрерывно изучает новые технологии, дорожит своим временем. Если в команде не отлажены процессы и разработчик простаивает без задач, если разработчик выполняет работу, которая никому не приносит пользы, если работа никак его не развивает, то он начинает ощущать, что тратит драгоценное время своей жизни впустую. Как результат, он уходит на другой проект. Скрам позволяет разработчику избежать прожигания жизни, помогает самореализоваться, ощутить свою причастность к важному делу.

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

Какой способ лучше? В каждом конкретном случае лучшим может быть любой из перечисленных или какой-то еще. Но я отдаю предпочтение почасовой оплате без использования трекера времени и далее я объясню почему. Отсутствие учета времени считаю вредным, поскольку может привести к ощущению ненужности вклада в общее дело, даже бесполезности участия в проекте. Учет времени, наоборот, добавляет ощущение важности и востребованности выполняемой разработчиком работы, помогает определить собственный темп, мотивирует к повышению собственной эффективности. Хочу обратить внимание на то, что разработчику важно, чтобы его труд оценивали не только по скорости выполнения задач, но и по качеству. Обязательно нужен человек, руководитель, который может оценить вклад разработчика. К сожалению, на многих проектах никого не интересует ни что делает разработчик, ни как он это делает, ни насколько быстро.

Иногда бывает, что скорость разработчика оценивается путем сравнения предварительно оцененного времени и фактически затраченного. То есть если разработчик опережает оценки, то его поощряют и наоборот. Считаю, что такая оценка должна использоваться как неточная, ориентировочная, второстепенная. Предварительная оценка времени (estimate) может быть сделана только приблизительно. Более точная оценка может быть сделана только в том случае, если подобные задачи решались многократно, однако повторяющиеся задачи встречаются нечасто. Даже обладая большим опытом и высокой точностью прогнозирования времени выполнения, вы не будете застрахованы от неожиданностей. Например, применение многократно использованной в других проектах библиотеки, оказало непредсказуемое влияние на систему, причем баг проявляется во время выполнения, и логи ни о чем не говорят. Если нет готового решения на StackOverflow, можно превысить Estimate в несколько раз. Надо понимать, что Estimate — это грубая оценка, которая может использоваться как ориентир. Превышение разработчиком Estimate, и если оно не является систематическим, не должно приводить к критике со стороны руководства.

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

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

Пусть удаленный разработчик оценил задачу в 2 часа, а выполнил ее за 1 ч 33 мин и записал это фактическое затраченное время в Tempo, перевел тикет в Code review и взял в работу следующий. Возникает вопрос, можем ли мы доверять разработчику, ведь он мог сделать эту задачу за 15 минут, а остальное время уделить онлайн играм или даже другим проектам? Ответ — да, можем доверять. Самое главное, на что должен обращать внимание SM, являются ли сотрудник эффективным, являются финансовые затраты на сотрудника приемлемыми в единицу времени. Обеспечивается ли такая скорость команды, которая позволит запустить MVP до окончания взлетной полосы стартапа. Во-первых, точные временные затраты на выполнение той или иной задачи да еще и при заданном уровне качества просто физически невозможно определить. У одного разработчика уйдет на это 2 часа, а у другого 15 минут, поскольку многое зависит от опыта и способностей. Кроме того, в любом проекте есть старожилы и новички. Старожил найдет решение за считанные минуты, в то время как новичок может потратить несколько дней на исследования. Во-вторых, разработчик может искать решение не только в момент написания кода, но и в любое нерабочее время. Идея может посетить человека совершенно неожиданно и в любой момент. Оценивать качество полученной идеи и ее реализации простым учетом времени, потраченного на кодирование, неэффективно. Это одна из причин низкой эффективности применения трекеров времени — разработчик работает не только в момент непосредственного написания кода. Ко всему, трекеры времени вносят элемент недоверия, превращают творческий процесс в каторгу.

Если SM не уверен в правдоподобности фактически списанного на задачу времени, он может заглянуть в GitLab и сопоставить изменения кода, сделанные по этой задаче, со списанным временем. Разработчик не может списать 2 часа за 2 строчки кода. Если SM не разбирается в программировании, он может пригласить эксперта для оценки реалистичности списанного времени, например SA. Как бы тами ни было, адекватный разработчик не будет списывать лишнее время, поскольку понимает, что реалистичность может быть проверена, а испорченную репутацию и доверие потом не восстановить.

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

Вернемся к разработчику, который выполнил задачу за 1 ч 33 мин и приступил к следующей. При этом, он списал за первую задачу 2 ч как было в Estimate. SM сможет легко определить, что интервал времени между переводом задачи в статус In Progress и Code review существенно меньше, чем списанное время. То есть факт приписки может быть легко установлен, обращать внимание разработчика на этот факт или нет, SM определяет сам. Конечно, разработчик может переводить задачи в те или иные статусы в точном соответствии со списанным временем, несмотря на то, что он не работал так много. Или он может переводить в In Progress сразу несколько тикетов, чтобы время начала работ было как можно более ранним — надо договориться о последовательном переводе тикетов в работу. В любом случае, не стоит беспокоиться! Напомню, для SM намного важнее польза, которую этот человек приносит за потраченные на него деньги в единицу времени. SM в любой момент может исключить любого члена команды из проекта, но это может привести к непредвиденным затратам на поиск и адаптацию нового члена команды, взятого взамен уволенному.

SM также может обратить внимание на то, что затраченное время всегда или почти всегда совпадает с Estimate. Для SM это звоночек, закрывать на это глаза или нет, решать ему в зависимости от ситуации.

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

Финансовые отношения

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

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