Что такое scrum доска

Что такое Scrum и как правильно использовать его в рабочем процессе

Что такое Scrum

Коротко говоря, Scrum — это способ организации рабочего процесса. Он пришел из мира разработки программного обеспечения и сейчас применяется в разных сферах бизнеса. Метод изобрели программисты Кен Швабер и Джефф Сазерленд. Они наблюдали за тем, как работают американские военные и спецназ и пришли к выводу, что основа успеха состоит в качественной командной работе. Сам же термин пришел из регби и в переводе с английского означает «схватка».

Scrum принадлежит к Аgile — семейству »гибких» подходов к организации процессов. Он состоит из минимального количества элементов, которые помогают успешно организовать работу. При помощи метода Scrum можно быстро и эффективно разработать принципиально новый продукт, аналогов которому нет на рынке.

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

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

Состав scrum-команды

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

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

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

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

Третий элемент команды — scrum-мастер. Он выступает в роли куратора и помогает коллективу сплотиться. Мастер проводит ежедневные собрания, помогает найти выход из тупикового этапа разработки и перевести команду на нужное направление. Главный успех scrum-мастера — сделать так, чтобы команда стала самоуправляемой и перестала в нем нуждаться. В идеале должны остаться только разработчики и владелец продукта.

Основные принципы работы по Scrum

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

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

Чем Scrum отличается от Kanban

Метод управления проектами Kanban также принадлежит семейству Agile. Но Scrum — это структурированный подход с четко прописанными этапами создания продукта, а Kanban — сбалансированный. Его главная задача — сделать так, чтобы у всех членов команды было одинаковое количество работы. В Kanban не должно быть переработок части команды и ситуаций, когда некоторые сотрудники осталась без задач и не знают чем себя занять.

Основное отличие двух методов — это спринты. В Scrum предусмотрены четко организованные периоды работы с конкретными задачами на период, а в Kanban участники команды могут получать новые задачи хоть каждый день. Scrum-команды выполняют работу на время, в Kanban задачи поступают в непрерывном режиме. Для отслеживания достижений и процесса в Kanban используют доски — элемент управления, который наглядно показывает уровень выполнения задач. В Scrum этой задаче служат окончания спринтов.

Преимущества Scrum

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

Вице-президент «Ренессанс страхование» Владимир Тарасов рассказал РБК Трендам, к каким результатам пришла компания после применения метода:

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

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

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

Недостатки Scrum

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

Владимир Тарасов:

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

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

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

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

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

Как внедрить Scrum для управления бизнес-процессами

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

Как внедрить Scrum в компанию

Подробную инструкцию по внедрению Scrum и о его процессах можно посмотреть в гайде или в книге от соавтора методологии Джеффа Сазерленда «Scrum: революционный метод управления проектами». О том, как правильно распоряжаться ресурсами и повышать личную эффективность, читайте в материале РБК Трендов про бережливое производство в жизни.

Источник

Scrum — нюансы применения в распределенной команде

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Процесс

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

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

Предположим, что члены команды живут в разных часовых поясах от Екатеринбурга до Чикаго. Оптимальным временем для митинга может быть, например 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, в которой записывается: что мы делаем, что мы начинаем делать и что мы прекращаем делать.

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

Учет времени

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

Хороший разработчик 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 это звоночек, закрывать на это глаза или нет, решать ему в зависимости от ситуации.

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

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

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

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

Источник