Попадание в оценки как метрика, часть 1
Подниму холиварный вопрос: "стоит ли измерять перформанс разработчиков точностью попадания в оценки?". Я считаю что стоит, если:
- налажен процесс оценки;
- есть рабочая система для измерения вылетов;
- не запускаются ракеты в космос, т.е. задачи относительно просты, подобные уже делались;
Эта метрика хороша тем, что ее легко измерить. Сложно (но возможно) оценить насколько эффективно программист делает код ревью или фиксит баги. Еще сложнее увидеть прогресс по сравнению с предыдущим периодом. Разумеется, стоит учитывать и другие показатели, при оценке сотрудников ☝️.
Взглянув на цифры в первый раз, я заметил насколько сильно попадание в оценки коррелирует с уровнем разработчиков. У тех, кого я считал "сильными" практически не было вылетов, и наоборот.
Если вы не закрыли канал до этого места, можно переходить к импрувам процесса оценки. К тем айтемам, что были описаны раньше, добавлю вот такие:
- задачи должны быть оценены до старта работ;
- оценивать должны те, кто будет делать задачу, причем не один человек, а вся команда;
- механику planning poker можно использовать, чтобы достичь договоренности в сложных тасках;
В следующем посте расскажу как построить систему измерения вылетов и как интерпретировать цифры.
Подниму холиварный вопрос: "стоит ли измерять перформанс разработчиков точностью попадания в оценки?". Я считаю что стоит, если:
- налажен процесс оценки;
- есть рабочая система для измерения вылетов;
- не запускаются ракеты в космос, т.е. задачи относительно просты, подобные уже делались;
Эта метрика хороша тем, что ее легко измерить. Сложно (но возможно) оценить насколько эффективно программист делает код ревью или фиксит баги. Еще сложнее увидеть прогресс по сравнению с предыдущим периодом. Разумеется, стоит учитывать и другие показатели, при оценке сотрудников ☝️.
Взглянув на цифры в первый раз, я заметил насколько сильно попадание в оценки коррелирует с уровнем разработчиков. У тех, кого я считал "сильными" практически не было вылетов, и наоборот.
Если вы не закрыли канал до этого места, можно переходить к импрувам процесса оценки. К тем айтемам, что были описаны раньше, добавлю вот такие:
- задачи должны быть оценены до старта работ;
- оценивать должны те, кто будет делать задачу, причем не один человек, а вся команда;
- механику planning poker можно использовать, чтобы достичь договоренности в сложных тасках;
В следующем посте расскажу как построить систему измерения вылетов и как интерпретировать цифры.
Попадание в оценки как метрика, часть 2
Чтобы мерить вылеты, в джире должно быть как в храме - чистота, порядок, ощущение величия. На практике это означает, что каждая фича разбивается на подзадачи (sub-task) и асайнится на разработчика, который будет ее делать. Затраченное время логается строго в подзадачу.
Набираем тикетов за период и строим выборку. Желательно брать статистику минимум за 2 месяца, чтобы получить достоверную цифру. Также нужно пройтись по всем таскам, которые попали в выборку и отфильтровать ненужные:
- багфикс и инвестигейты (их лучше вообще не оценивать);
- задачи, которые начал один сотрудник, а закончил другой;
- подозрительные тикеты (плохо оцененные изначально, измененные по ходу и т.д.)
Гаджет Rich filter Statistics визуализирует данные. Если гаджета нет, можно сделать выгрузку в эксель и посчитать вылет, поделив original estimate на time spent. В итоге должно получиться примерно как на картинке внизу.
Теперь анализируем результат. Вылет до 25% - ок, все что больше - не ок. Кроме персонального вылета полезно исследовать еще две цифры:
1. Общий вылет по команде. В соотношении с личным вылетом, можно сделать какие-то выводы.
2. Общий вылет по технологии (если их больше 1). Похоже на предыдущее, только выборка уже, а результат репрезентативнее. Логичнее же сравнивать оценки андроид команды между собой, чем с бекендом+тестировщиками.
Чтобы мерить вылеты, в джире должно быть как в храме - чистота, порядок, ощущение величия. На практике это означает, что каждая фича разбивается на подзадачи (sub-task) и асайнится на разработчика, который будет ее делать. Затраченное время логается строго в подзадачу.
Набираем тикетов за период и строим выборку. Желательно брать статистику минимум за 2 месяца, чтобы получить достоверную цифру. Также нужно пройтись по всем таскам, которые попали в выборку и отфильтровать ненужные:
- багфикс и инвестигейты (их лучше вообще не оценивать);
- задачи, которые начал один сотрудник, а закончил другой;
- подозрительные тикеты (плохо оцененные изначально, измененные по ходу и т.д.)
Гаджет Rich filter Statistics визуализирует данные. Если гаджета нет, можно сделать выгрузку в эксель и посчитать вылет, поделив original estimate на time spent. В итоге должно получиться примерно как на картинке внизу.
Теперь анализируем результат. Вылет до 25% - ок, все что больше - не ок. Кроме персонального вылета полезно исследовать еще две цифры:
1. Общий вылет по команде. В соотношении с личным вылетом, можно сделать какие-то выводы.
Пример 1: общий = 25%, личный = 10% - сотрудник молодец.Пример 2: общий = 10%, личный = 25%. Хоть 25 и находится на приемлемой границе, остальная команда вылетает меньше, нужно разбирать почему у сотрудника не получается вкладываться в оценки.Пример 3: Общий = 40%, личный = 40%. Хоть 40 и превышает приемлемую границу, у остальной команды тот же результат. Вероятно, проблема в процессах, оценках, чем-то еще.2. Общий вылет по технологии (если их больше 1). Похоже на предыдущее, только выборка уже, а результат репрезентативнее. Логичнее же сравнивать оценки андроид команды между собой, чем с бекендом+тестировщиками.
Сердце Скрама
В скрам гайде есть глава Scrum Theory, где описаны 3 основы эмпирического подхода (pillars of empiricism):
- Transparency - представлять факты в их истинном свете, доставлять нужным людям нужную инфу, быть на одной странице;
- Inspection - проверять процессы / продукт / людей / практики;
- Adoption - исправлять косяки, найденные в предыдущем пункте;
Вокруг них строится весь фреймворк. Это как фундамент дома - без него никак. Скрам работает не благодаря ролям, ивентам и артефактам, а именно из-за этих принципов. Сравниться с ними по значению могут только ценности, также включенные в скрам гайд - commitment, courage, focus, openness and respect.
В скрам гайде есть глава Scrum Theory, где описаны 3 основы эмпирического подхода (pillars of empiricism):
- Transparency - представлять факты в их истинном свете, доставлять нужным людям нужную инфу, быть на одной странице;
- Inspection - проверять процессы / продукт / людей / практики;
- Adoption - исправлять косяки, найденные в предыдущем пункте;
Вокруг них строится весь фреймворк. Это как фундамент дома - без него никак. Скрам работает не благодаря ролям, ивентам и артефактам, а именно из-за этих принципов. Сравниться с ними по значению могут только ценности, также включенные в скрам гайд - commitment, courage, focus, openness and respect.
Куда расти проджект менеджеру
Если отвечать за скоуп, бюджет и срок уже скучно, посмотрите каким еще менеджером можно стать:
Resource - хэд отдела ПМов, такие встречаются в компаниях 100+ человек. Помогает менеджерам расти, нанимает новых, распределяет между проектами. Иисус, наверное, был RMом - без любви к человеку здесь никак.
Delivery - отвечает за успех проекта перед компанией с точки зрения производства. Умеет решать самые сложные проблемы. Помогает ПМ в стратегических вопросах, подключается при пожарах. Техническая экспертиза - маст хэв.
Programm - ПМ ПМов. Бывает заказчику так нравится тратить деньги на одну команду, что он покупает еще несколько. У каждой из этих тим есть менеджер, а самый главный из них - программ.
Account - развивает отношения с существующим клиентом. Главный по контрактам, доп. продажам, сбору фидбека и поздравлениям на праздники.
Sales - такой рост может показаться горизонтальным, но присмотритесь чем занимается c-level духовенство. Самые крупными сделки обычно заключают топы.
Product - отвечает за фичи, метрики, пользователей, прибыль. В СНГ сейчас бум на эту специальность, много вакансий, курсов, конференций. Классный опыт, чтобы потом запустить свой проект.
Если отвечать за скоуп, бюджет и срок уже скучно, посмотрите каким еще менеджером можно стать:
Resource - хэд отдела ПМов, такие встречаются в компаниях 100+ человек. Помогает менеджерам расти, нанимает новых, распределяет между проектами. Иисус, наверное, был RMом - без любви к человеку здесь никак.
Delivery - отвечает за успех проекта перед компанией с точки зрения производства. Умеет решать самые сложные проблемы. Помогает ПМ в стратегических вопросах, подключается при пожарах. Техническая экспертиза - маст хэв.
Programm - ПМ ПМов. Бывает заказчику так нравится тратить деньги на одну команду, что он покупает еще несколько. У каждой из этих тим есть менеджер, а самый главный из них - программ.
Account - развивает отношения с существующим клиентом. Главный по контрактам, доп. продажам, сбору фидбека и поздравлениям на праздники.
Sales - такой рост может показаться горизонтальным, но присмотритесь чем занимается c-level духовенство. Самые крупными сделки обычно заключают топы.
Product - отвечает за фичи, метрики, пользователей, прибыль. В СНГ сейчас бум на эту специальность, много вакансий, курсов, конференций. Классный опыт, чтобы потом запустить свой проект.
Орки
Иногда кажется, что вокруг одни орки. Не могут нормально сделать фичу, просят уложиться в нереальные сроки, не сдерживают обещаний.
Раньше я часто так думал, а потом несколько коллег написали мне в фидбеке что я конфликтный (т.к. боролся с орками). Я стал прикидывать что делаю не так и понял, что упускаю простую, но важную вещь - мотивацию. Оказалось, что за событиями, которые меня бесили, всегда стояла какая-то причина. Найти ее сложно, но почти всегда она есть. Фича сделана плохо, потому что у разработчика болел ребенок, и ему не до этого. Сроки нереальные, потому что надо успеть к решающей выставке. Когда эту мотивацию выясняешь, оказывается, что настоящих орков крайне мало.
Люди редко что-то делают назло, чаще у них есть какие-то причины:
- не понимают (нет четкой и обоснованной цели);
- не умеют или не знают;
- не могут;
- не хотят;
- и только потом уже саботаж;
Always assume positive intent!
Иногда кажется, что вокруг одни орки. Не могут нормально сделать фичу, просят уложиться в нереальные сроки, не сдерживают обещаний.
Раньше я часто так думал, а потом несколько коллег написали мне в фидбеке что я конфликтный (т.к. боролся с орками). Я стал прикидывать что делаю не так и понял, что упускаю простую, но важную вещь - мотивацию. Оказалось, что за событиями, которые меня бесили, всегда стояла какая-то причина. Найти ее сложно, но почти всегда она есть. Фича сделана плохо, потому что у разработчика болел ребенок, и ему не до этого. Сроки нереальные, потому что надо успеть к решающей выставке. Когда эту мотивацию выясняешь, оказывается, что настоящих орков крайне мало.
Люди редко что-то делают назло, чаще у них есть какие-то причины:
- не понимают (нет четкой и обоснованной цели);
- не умеют или не знают;
- не могут;
- не хотят;
- и только потом уже саботаж;
Always assume positive intent!
Орлопан
Первые курсы ПМ, на которые я ходил, вели Александр Орлов и Слава Панкратов. Это была одна из лучших инвестиций в обучение. Ребята основали школу менеджеров Стратоплан и выпускают много полезного контента вместе, за что мой босс прозвал их "Орлопан". Из бесплатного и наиболее ценного - блог их компании. Несколько топовых книг:
1. Как стать менеджером в ИТ - для тех, кто делает свои первые шаги в профессии ПМ.
2. Черная книга менеджера - сами авторы называют "прививка от чмошности". Красочный монолог владельца компании о менеджере, который у него работает.
3. Белая книжная полка для менеджеров - сборник практических статей по основным вехам в управлении проектами.
Друзья, никакой коммерции, рекомендую только то, что читаю сам.
Первые курсы ПМ, на которые я ходил, вели Александр Орлов и Слава Панкратов. Это была одна из лучших инвестиций в обучение. Ребята основали школу менеджеров Стратоплан и выпускают много полезного контента вместе, за что мой босс прозвал их "Орлопан". Из бесплатного и наиболее ценного - блог их компании. Несколько топовых книг:
1. Как стать менеджером в ИТ - для тех, кто делает свои первые шаги в профессии ПМ.
2. Черная книга менеджера - сами авторы называют "прививка от чмошности". Красочный монолог владельца компании о менеджере, который у него работает.
3. Белая книжная полка для менеджеров - сборник практических статей по основным вехам в управлении проектами.
Друзья, никакой коммерции, рекомендую только то, что читаю сам.
Эпик фейл
Как-то раз я получил самое обычное письмо от заказчика. Проблема была технической и я попросил разработчика ответить. Вопрос решился, заказчик остался доволен и даже написал что мы молодцы. Он был не самым эмоциональным американцем и немного скупым на добрые слова. Я решил воспользоваться этим и похвалить разработчика, это было одно из первых его писем. Пишу в тот же тред: "молодец, он обычно хмуро отвечает". Вскоре приходит ответ, тоже на русском: "Я не есть хмурый". От заказчика.🙄
Эта история научила меня проверять получателей письма, прежде чем нажать кнопку отправить. Если письмо очень важное, лучше сначала написать ответ (и перечитать!), а получателей добавить прямо перед отправкой.
Фейлы бывают у всех и это ОК. Говорят даже, что фейл ценнее успеха, если сделать выводы. Давайте попробуем поучиться на чужих ошибках. Скиньте в дм самые эпичные фейлы, составлю анонимную подборку.
Как-то раз я получил самое обычное письмо от заказчика. Проблема была технической и я попросил разработчика ответить. Вопрос решился, заказчик остался доволен и даже написал что мы молодцы. Он был не самым эмоциональным американцем и немного скупым на добрые слова. Я решил воспользоваться этим и похвалить разработчика, это было одно из первых его писем. Пишу в тот же тред: "молодец, он обычно хмуро отвечает". Вскоре приходит ответ, тоже на русском: "Я не есть хмурый". От заказчика.🙄
Эта история научила меня проверять получателей письма, прежде чем нажать кнопку отправить. Если письмо очень важное, лучше сначала написать ответ (и перечитать!), а получателей добавить прямо перед отправкой.
Фейлы бывают у всех и это ОК. Говорят даже, что фейл ценнее успеха, если сделать выводы. Давайте попробуем поучиться на чужих ошибках. Скиньте в дм самые эпичные фейлы, составлю анонимную подборку.
Друзья, получил ваши весточки, огромное спасибо всем откликнувшимся. Текста много, скомпилировал все в телеграф для вашего комфорта.
Telegraph
Эпичные фейлы
Roger that работаю autoQA, периодически отправляю отчеты по прогонам автотестов заказчику. и так получилось, что я ему скинул отчет с ошибкой в подписи. у нас с ним были теплые и хорошие отношения, и он по-дружески решил меня поправить в личке. после полученного…
Чек-лист оценки проекта, часть 1
Продакшн часто жалуется на сейлов, которые пообещали клиенту золотые горы по цене несколько другого материала. В компаниях со зрелыми процессами ПМ сам оценивает проект и сопровождает продажу вместе с сейлом. Положим, оценка уже сделана и вроде бы можно ее отправлять. Ниже чек-лист что нужно не забыть включить:
- WBS;
- краткое описание задач. Например, логин\регистрация - имейл, Facebook, телефон (без СМС подтверждения);
- PM+BA / DEV / QA пропорция в оценке примерно попадает в 15%/55%/30%;
- стек технологий;
- рейты согласованны с сейлом;
- все необходимые виды тестирования (авто, юнит, перфоманс, секьюрити), перечислены поддерживаемые устройства \ ОС \ браузеры;
- закупаемые за счет клиента устройства;
- риски и асампшены;
- состав команды (специальности и количество);
- длительность проекта, желательно с визуализацией (гант чарт или разбивка по фазам);
- ссылка на доки, на основе которых сделана оценка;
Продакшн часто жалуется на сейлов, которые пообещали клиенту золотые горы по цене несколько другого материала. В компаниях со зрелыми процессами ПМ сам оценивает проект и сопровождает продажу вместе с сейлом. Положим, оценка уже сделана и вроде бы можно ее отправлять. Ниже чек-лист что нужно не забыть включить:
- WBS;
- краткое описание задач. Например, логин\регистрация - имейл, Facebook, телефон (без СМС подтверждения);
- PM+BA / DEV / QA пропорция в оценке примерно попадает в 15%/55%/30%;
- стек технологий;
- рейты согласованны с сейлом;
- все необходимые виды тестирования (авто, юнит, перфоманс, секьюрити), перечислены поддерживаемые устройства \ ОС \ браузеры;
- закупаемые за счет клиента устройства;
- риски и асампшены;
- состав команды (специальности и количество);
- длительность проекта, желательно с визуализацией (гант чарт или разбивка по фазам);
- ссылка на доки, на основе которых сделана оценка;
Habr
Преимущества Иерархической Структуры Работ (WBS) для менеджеров ИТ проектов
Имеющие дело со сложными ИТ проектами руководители подтвердят, что разделение задач на более мелкие и управляемые части делает рабочий процесс намного проще. В этой статье расскажу о процессе,...
Крисмас
Рождество не за горами, коллеги, не забудьте поздравить клиентов, это очень важно. Такие мелочи как открытки и сувениры (и их отсутствие) они любят и помнят. Если совсем не успеваете, напишите проникновенное письмо, да прикрепите блаженное фото команды.
Мой заказчик записал поздравительное видео, поэтому теперь боженька по вечерам нашептывает сценарий ответной короткометражки. Пошарить, к сожалению, не могу из-за NDA.
Всем удачных праздников!
Рождество не за горами, коллеги, не забудьте поздравить клиентов, это очень важно. Такие мелочи как открытки и сувениры (и их отсутствие) они любят и помнят. Если совсем не успеваете, напишите проникновенное письмо, да прикрепите блаженное фото команды.
Мой заказчик записал поздравительное видео, поэтому теперь боженька по вечерам нашептывает сценарий ответной короткометражки. Пошарить, к сожалению, не могу из-за NDA.
Всем удачных праздников!
Размер команды
Джеф Безос, основатель Амазон, считает что оптимальный размер команды - 6-7 человек. Назвал он это правило "2-pizza team", потому что именно столько нужно человек, чтобы съесть 2 большие пиццы 🍕.
В скраме похожая ситуация. Предлагают команду в 3-9 человек без учета СМ и ПО. Больше 9 - падает эффективность в коммуникациях и управлении. Меньше 3 - сложно разработать достаточный объем ценности за спринт.
Если на проекте 10+ человек, можно выделить несколько под-команд. Сразу возникает вопрос по какому признаку их организовать? Я видел два хорошо работающих варианта:
1. По фичам, если проект можно разбить на крупные модули (продукты, эпики). Тогда будет команда модуля 1 и команда модуля 2. Для своего проекта выбрал этот вариант.
2. По направлениям работы - команда поддержки, архитектуры, быстродействия, отказоустойчивости и т.д.
Джеф Безос, основатель Амазон, считает что оптимальный размер команды - 6-7 человек. Назвал он это правило "2-pizza team", потому что именно столько нужно человек, чтобы съесть 2 большие пиццы 🍕.
В скраме похожая ситуация. Предлагают команду в 3-9 человек без учета СМ и ПО. Больше 9 - падает эффективность в коммуникациях и управлении. Меньше 3 - сложно разработать достаточный объем ценности за спринт.
Если на проекте 10+ человек, можно выделить несколько под-команд. Сразу возникает вопрос по какому признаку их организовать? Я видел два хорошо работающих варианта:
1. По фичам, если проект можно разбить на крупные модули (продукты, эпики). Тогда будет команда модуля 1 и команда модуля 2. Для своего проекта выбрал этот вариант.
2. По направлениям работы - команда поддержки, архитектуры, быстродействия, отказоустойчивости и т.д.
Как продать рефакторинг
Не все заказчики технические и понимают зачем нужен рефакторинг. Им ясна логика "фича х принесет y денег", а ценность рефакторинга туманна. Мы-то с вами знаем, что она есть, ее нужно просто сформулировать:
- Быстродействие. Картинки на сайте будут грузиться быстрее, это увеличит конверсию.
- Масштабируемость и отказоустойчивость. Если на сайт придет 1000 человек, он продолжит работать как обычно, а не ляжет.
- Безопасность. Злодеям и смутьянам будет сложнее украсть данные ваших пользователей.
- Дешевле поддерживать. Перепелим вот этот кусок и в нем станет меньше багов, а оставшиеся будет быстрее пофиксить.
- Дешевле добавлять новые фичи. Сейчас внедрение нового метода оплаты занимает x часов, а будет x/2.
Разговаривайте с бизнесом на его языке.
Не все заказчики технические и понимают зачем нужен рефакторинг. Им ясна логика "фича х принесет y денег", а ценность рефакторинга туманна. Мы-то с вами знаем, что она есть, ее нужно просто сформулировать:
- Быстродействие. Картинки на сайте будут грузиться быстрее, это увеличит конверсию.
- Масштабируемость и отказоустойчивость. Если на сайт придет 1000 человек, он продолжит работать как обычно, а не ляжет.
- Безопасность. Злодеям и смутьянам будет сложнее украсть данные ваших пользователей.
- Дешевле поддерживать. Перепелим вот этот кусок и в нем станет меньше багов, а оставшиеся будет быстрее пофиксить.
- Дешевле добавлять новые фичи. Сейчас внедрение нового метода оплаты занимает x часов, а будет x/2.
Разговаривайте с бизнесом на его языке.
Скелет ретроспективы
В аду нет столько грешников, сколько существует вариантов проведения ретроспективы. Выбрать можно любой, главное не забывать о цели. Основной гол по скрамгайду - пересмотр и улучшение процессов и практик, дабы повысить эффективность разработки. Попробую добавить конкретики.
Важно:
1. Ревью договоренностей предыдущей ретры. Если они не выполняются, проку от таких митингов мало.
2. Классический подход что было хорошо / что было плохо / что стоит попробовать.
3. Ревью результатов прошедшего спринта (сделали ли то, на что закомитились).
4. Фидбек от заказчика, если есть.
Опционально:
1. Icebreaker.
2. Выяснить настроение команды. Короткий вопрос "как для тебя прошел спринт?" с вариантами ответа зеленый (= все хорошо), желтый и красный (= все плохо). Помогает найти потенциальные проблемы, с красными стоит провести личную встречу.
3. Рассказать о новостях компании, проекта, долгосрочных планах.
В аду нет столько грешников, сколько существует вариантов проведения ретроспективы. Выбрать можно любой, главное не забывать о цели. Основной гол по скрамгайду - пересмотр и улучшение процессов и практик, дабы повысить эффективность разработки. Попробую добавить конкретики.
Важно:
1. Ревью договоренностей предыдущей ретры. Если они не выполняются, проку от таких митингов мало.
2. Классический подход что было хорошо / что было плохо / что стоит попробовать.
3. Ревью результатов прошедшего спринта (сделали ли то, на что закомитились).
4. Фидбек от заказчика, если есть.
Опционально:
1. Icebreaker.
2. Выяснить настроение команды. Короткий вопрос "как для тебя прошел спринт?" с вариантами ответа зеленый (= все хорошо), желтый и красный (= все плохо). Помогает найти потенциальные проблемы, с красными стоит провести личную встречу.
3. Рассказать о новостях компании, проекта, долгосрочных планах.
Друзья,
Боженька сбросил смску, просит поздравить всех с наступающим. Желает:
- больше благодарных и понимающих клиентов;
- меньше проектов с поддержкой IE7;
- доставлять ценность и чтобы почаще ее доставляли лично вам.
Попросил его подарить больше баджета подписчикам на следующий год, сказал, что подумает.
P.S. А менеджер уходит в творческий отпуск, увидимся в феврале.
Боженька сбросил смску, просит поздравить всех с наступающим. Желает:
- больше благодарных и понимающих клиентов;
- меньше проектов с поддержкой IE7;
- доставлять ценность и чтобы почаще ее доставляли лично вам.
Попросил его подарить больше баджета подписчикам на следующий год, сказал, что подумает.
P.S. А менеджер уходит в творческий отпуск, увидимся в феврале.
Как работают американские команды
Привет, коллеги! Я снова с вами и сейчас расскажу где пропадал. Две недели января я провел у своего клиента в солнечной Алабаме. Было любопытно посмотреть на их работу оффлайн и мне не терпится поделиться этим опытом с вами. Эти заметки передают скорее мои личные ощущения о поездке, чем претендуют на роль мерила софтверной индустрии США. Очень может быть что в других компаниях все совсем по-другому.
Компания
Большую часть значимой инфы я узнавал буквально случайно. Особенно эффективны для этого обеды, тимбилдинги, курилки и бары. Это одно из главных преимуществ нахождения онсайт. Важные сведения могут просто не дойти до вас, когда вы в другой стране и общаетесь по имейлу и телефону. Именно так выяснилось, что клиент ищет вендора для проекта по машинному обучению (он не знал, что в моей компании есть такая экспертиза), который мы сейчас оцениваем.
В компании работает около 600 человек, людей, принимающих решения много. Не со всеми из них я был знаком лично. Основной задачей было понять кто именно владеет бюджетом и с кем надо дружить. Так я нашел несколько новых контактов.
Раньше мы конфликтовали с архитектором Брайаном по каждой мелочи. Он решил это исправить и позвал меня в бар. Через пару часов мы уже смотрели его свадебные фотки 😀. Оказался отличным парнем, теперь он мой лучший алабамский друг. Когда к рабочим отношениям добавляется хотя бы капля личного, вопросы решаются в разы проще. За бизнес-задачами появляются живые люди со своей историей, проблемами, желаниями. Это сближает и ускоряет процесс.
Получить письмо "у нас не работает Х, почините скорее, это очень важно" это одно. Со временем к такого рода сообщениям вообще вырабатывается иммунитет. Совсем другое дело увидеть этот Х вживую и его негативный эффект. Когда реальные деньги сгорают на твоих глазах, становится гораздо понятнее почему тебя пушат и почему так важно что-то быстро сделать.
Ассимилироваться было просто, потому что все, с кем я общался, были очень открытыми, доброжелательными и вежливыми. Это справедливо не только для ИТ сферы, но и для большинства жителей США. Разница особенно хорошо заметна на контрасте с общением в СНГ. На одной ретроспективе мне буквально сказали "Рома, ты здесь единственный представитель офшор команды, а нас в этой комнате 4. Мы не хотим задавить тебя числом и будем стараться, чтобы тебе было максимально комфортно". Класс!
В офис можно приходить с собаками, если они воспитанные и не шкодят. Это немного расслабляет, делает атмосферу более неформальной и домашней.
Привет, коллеги! Я снова с вами и сейчас расскажу где пропадал. Две недели января я провел у своего клиента в солнечной Алабаме. Было любопытно посмотреть на их работу оффлайн и мне не терпится поделиться этим опытом с вами. Эти заметки передают скорее мои личные ощущения о поездке, чем претендуют на роль мерила софтверной индустрии США. Очень может быть что в других компаниях все совсем по-другому.
Компания
Большую часть значимой инфы я узнавал буквально случайно. Особенно эффективны для этого обеды, тимбилдинги, курилки и бары. Это одно из главных преимуществ нахождения онсайт. Важные сведения могут просто не дойти до вас, когда вы в другой стране и общаетесь по имейлу и телефону. Именно так выяснилось, что клиент ищет вендора для проекта по машинному обучению (он не знал, что в моей компании есть такая экспертиза), который мы сейчас оцениваем.
В компании работает около 600 человек, людей, принимающих решения много. Не со всеми из них я был знаком лично. Основной задачей было понять кто именно владеет бюджетом и с кем надо дружить. Так я нашел несколько новых контактов.
Раньше мы конфликтовали с архитектором Брайаном по каждой мелочи. Он решил это исправить и позвал меня в бар. Через пару часов мы уже смотрели его свадебные фотки 😀. Оказался отличным парнем, теперь он мой лучший алабамский друг. Когда к рабочим отношениям добавляется хотя бы капля личного, вопросы решаются в разы проще. За бизнес-задачами появляются живые люди со своей историей, проблемами, желаниями. Это сближает и ускоряет процесс.
Получить письмо "у нас не работает Х, почините скорее, это очень важно" это одно. Со временем к такого рода сообщениям вообще вырабатывается иммунитет. Совсем другое дело увидеть этот Х вживую и его негативный эффект. Когда реальные деньги сгорают на твоих глазах, становится гораздо понятнее почему тебя пушат и почему так важно что-то быстро сделать.
Ассимилироваться было просто, потому что все, с кем я общался, были очень открытыми, доброжелательными и вежливыми. Это справедливо не только для ИТ сферы, но и для большинства жителей США. Разница особенно хорошо заметна на контрасте с общением в СНГ. На одной ретроспективе мне буквально сказали "Рома, ты здесь единственный представитель офшор команды, а нас в этой комнате 4. Мы не хотим задавить тебя числом и будем стараться, чтобы тебе было максимально комфортно". Класс!
В офис можно приходить с собаками, если они воспитанные и не шкодят. Это немного расслабляет, делает атмосферу более неформальной и домашней.
Команда
В команде разработки много дисциплины, американцы всерьёз относятся к своему профессионализму. На стендапы в 8.45 никто ни разу не опоздал. Менеджмент и лиды часто отвечают в нерабочее время. При этом в 5 вечера всех как ветром сдуло.
Большую роль играет фидбек от продактов и топов. Буквально говорят: "этой фичей вы сэкономили саппорту х часов работы = y денег". Команде не вливают "вы такие классные, спасибо", а показывают реальную пользу, которую они приносят. Это сильно мотивирует.
Токсичность и формализм напрочь отсутствуют. Ребята подкалывают друг друга, работать весело! Я однозначно не назову свою команду унылой, наверное, эти парни просто сидят на коксе 😆. Ощущается дух партнёрства, общей цели и вот этого всего. Большинство разработчиков пришли меньше полугода назад, но сколько в них смелости на ретроспективе! Напрямую говорят о проблемах, не замалчивают их, при этом оставаясь конструктивными. Красота.
На 20 разработчиков приходится 0 тестировщиков. Роль QA исполняют эти же 20 человек. Команда практикует CD, и мануальное тестирование в нем присутствует. Каждый пулл реквест должен получить 3 апрува на код ревью. Эти же три человека проверяют фичу вручную. На эту активность закладывается 1 час в день при планировании. В среднем, откатываются раз в 3-4 месяца, что говорит о том, что подход работает (хотя я так и не понял как это возможно).
Вся команда - фулстек. Конечно, кто-то больше знает бек, кто-то фронт, но считается, что любую фичу может сделать в любой разработчик. А если не может - должен учиться.
В процессах самый обычный скрам с двухнедельными спринтами. Какой-то большой разницы с тем, как работают у нас, я не заметил.
-----------------
Это была моя вторая рабочая командировка в США. Разумеется, огромную роль в таких поездках играют подготовка и стратегия поведения на месте. Если вам интересно об этом послушать ставьте 👍, расскажу об этом в следующих постах.
В команде разработки много дисциплины, американцы всерьёз относятся к своему профессионализму. На стендапы в 8.45 никто ни разу не опоздал. Менеджмент и лиды часто отвечают в нерабочее время. При этом в 5 вечера всех как ветром сдуло.
Большую роль играет фидбек от продактов и топов. Буквально говорят: "этой фичей вы сэкономили саппорту х часов работы = y денег". Команде не вливают "вы такие классные, спасибо", а показывают реальную пользу, которую они приносят. Это сильно мотивирует.
Токсичность и формализм напрочь отсутствуют. Ребята подкалывают друг друга, работать весело! Я однозначно не назову свою команду унылой, наверное, эти парни просто сидят на коксе 😆. Ощущается дух партнёрства, общей цели и вот этого всего. Большинство разработчиков пришли меньше полугода назад, но сколько в них смелости на ретроспективе! Напрямую говорят о проблемах, не замалчивают их, при этом оставаясь конструктивными. Красота.
На 20 разработчиков приходится 0 тестировщиков. Роль QA исполняют эти же 20 человек. Команда практикует CD, и мануальное тестирование в нем присутствует. Каждый пулл реквест должен получить 3 апрува на код ревью. Эти же три человека проверяют фичу вручную. На эту активность закладывается 1 час в день при планировании. В среднем, откатываются раз в 3-4 месяца, что говорит о том, что подход работает (хотя я так и не понял как это возможно).
Вся команда - фулстек. Конечно, кто-то больше знает бек, кто-то фронт, но считается, что любую фичу может сделать в любой разработчик. А если не может - должен учиться.
В процессах самый обычный скрам с двухнедельными спринтами. Какой-то большой разницы с тем, как работают у нас, я не заметил.
-----------------
Это была моя вторая рабочая командировка в США. Разумеется, огромную роль в таких поездках играют подготовка и стратегия поведения на месте. Если вам интересно об этом послушать ставьте 👍, расскажу об этом в следующих постах.
Unit тесты
«Да кому нужны эти юниты? У нас тестировщик в команде на что?» — сказал Саша, веб-разработчик на нашем новом проекте. Я был новичком и принял его слова за истину в последней инстанции. Первая пара месяцев прошла нормально, а где-то через полгода нас накрыло волной праведной регрессии. Большая часть времени уходила на багфикс, и это жутко всех расстраивало. Проект закончился, и на последней ретроспективе все согласились, что отказ от тестов был ужасной идеей.
Но все не так однозначно. В определенных случаях от тестов действительно можно отказаться. К сожалению, точного правила когда их писать, а когда нет, боженька нам не предоставил, придется решать самим. Прежде, чем это сделать, обозначим какой прок от этих тестов.
Плюсы:
- меньше регрессионных багов -> меньше времени на стабилизацию;
- более быстрый процесс поставки (первый шаг к CI\CD);
- проще дебажить код;
- улучшение архитектуры;
Минусы:
- написание тестов занимает время (0.3-0.9 от времени разработки, из того что я встречал);
- поддержка тестов занимает время (помимо исправления выломанной фичи, разработчик тратит время еще и на исправление тестов);
- написание тестов может попросту не оправдать себя. Некоторые проекты пишутся небольшими фазами, которые покупает клиент одну за одной. Команда не знает, сколько фаз продлится проект. Имея контракт только на 1 фазу, скажем, в два месяца, дешевле будет проверить функционал руками, чем писать тесты. Другой пример - прототипы, PoC.
Теперь можно прикинуть пару критериев, для ответа на вопрос "стоит ли писать тесты?":
- длительность проекта (если > 3-4K часов, то стоит писать);
- частота релизов и требования к поставкам (деплой раз в неделю без тестов может не взлететь);
- тип проекта (если много юая, и мало логики, возможно, авто тесты больше подойдут);
- контракт и прочие церковно-политические условия;
«Да кому нужны эти юниты? У нас тестировщик в команде на что?» — сказал Саша, веб-разработчик на нашем новом проекте. Я был новичком и принял его слова за истину в последней инстанции. Первая пара месяцев прошла нормально, а где-то через полгода нас накрыло волной праведной регрессии. Большая часть времени уходила на багфикс, и это жутко всех расстраивало. Проект закончился, и на последней ретроспективе все согласились, что отказ от тестов был ужасной идеей.
Но все не так однозначно. В определенных случаях от тестов действительно можно отказаться. К сожалению, точного правила когда их писать, а когда нет, боженька нам не предоставил, придется решать самим. Прежде, чем это сделать, обозначим какой прок от этих тестов.
Плюсы:
- меньше регрессионных багов -> меньше времени на стабилизацию;
- более быстрый процесс поставки (первый шаг к CI\CD);
- проще дебажить код;
- улучшение архитектуры;
Минусы:
- написание тестов занимает время (0.3-0.9 от времени разработки, из того что я встречал);
- поддержка тестов занимает время (помимо исправления выломанной фичи, разработчик тратит время еще и на исправление тестов);
- написание тестов может попросту не оправдать себя. Некоторые проекты пишутся небольшими фазами, которые покупает клиент одну за одной. Команда не знает, сколько фаз продлится проект. Имея контракт только на 1 фазу, скажем, в два месяца, дешевле будет проверить функционал руками, чем писать тесты. Другой пример - прототипы, PoC.
Теперь можно прикинуть пару критериев, для ответа на вопрос "стоит ли писать тесты?":
- длительность проекта (если > 3-4K часов, то стоит писать);
- частота релизов и требования к поставкам (деплой раз в неделю без тестов может не взлететь);
- тип проекта (если много юая, и мало логики, возможно, авто тесты больше подойдут);
- контракт и прочие церковно-политические условия;
Как готовиться к командировке
Первый вопрос, на который надо ответить - "а зачем вообще куда-то ехать?". Потусоваться в другой стране, конечно, прикольно, но, имея четкую цель, значительно проще достигнуть результата. Более того, командировки стоят денег и человек, который их платит, будь то заказчик или босс, должен хорошо понимать, что он получит взамен. Поэтому, главное, что нужно понять - для чего нужна поездка.
Когда цель ясна, можно формировать агенду. Набросайте вопросов, которые хотите решить, потом сгруппируйте, например так. Полезно:
- выслать план стейкхолдерам, наверняка им будет что добавить;
-сделать опросник для команды "что хотите обсудить с заказчиком?";
- положить агенду на вики и обновлять по ходу поездки. В будущем можно использовать в качестве отчета менеджменту или команде;
- пункт "провести ретроспективу \ получить фидбек" подходит практически к любой командировке;
Частой задачей командировок являются доп продажи. Продавать можно не только расширение текущих проектов (здесь что-то сложно советовать без контекста), но и новые. Рабочий вариант - изучить другие продукты компании (доступ в гит сильно упростит задачу), придумать фичи \ улучшения, предложить заказчику.
Главной ошибкой, которую я совершил было не запланировать встречи заранее. Подумал, что сделаю это на месте, но не учел, что у людей уже были планы. Из-за этого не смог решить несколько вопросов, требовавших участия большого количества стейкхолдеров (а чем их больше, тем труднее собрать всех в одно время). Вынес для себя урок: как только агенда готова - сразу же ставить митинги.
Возвращаясь к целям командировки, одна из них всегда будет выполнена - посветить лицом (прости, господи). Личный контакт часто оказывается важнее всего остального, т.к. в конечном итоге люди работают с людьми, а не вендоры с заказчиками.
Первый вопрос, на который надо ответить - "а зачем вообще куда-то ехать?". Потусоваться в другой стране, конечно, прикольно, но, имея четкую цель, значительно проще достигнуть результата. Более того, командировки стоят денег и человек, который их платит, будь то заказчик или босс, должен хорошо понимать, что он получит взамен. Поэтому, главное, что нужно понять - для чего нужна поездка.
Когда цель ясна, можно формировать агенду. Набросайте вопросов, которые хотите решить, потом сгруппируйте, например так. Полезно:
- выслать план стейкхолдерам, наверняка им будет что добавить;
-сделать опросник для команды "что хотите обсудить с заказчиком?";
- положить агенду на вики и обновлять по ходу поездки. В будущем можно использовать в качестве отчета менеджменту или команде;
- пункт "провести ретроспективу \ получить фидбек" подходит практически к любой командировке;
Частой задачей командировок являются доп продажи. Продавать можно не только расширение текущих проектов (здесь что-то сложно советовать без контекста), но и новые. Рабочий вариант - изучить другие продукты компании (доступ в гит сильно упростит задачу), придумать фичи \ улучшения, предложить заказчику.
Главной ошибкой, которую я совершил было не запланировать встречи заранее. Подумал, что сделаю это на месте, но не учел, что у людей уже были планы. Из-за этого не смог решить несколько вопросов, требовавших участия большого количества стейкхолдеров (а чем их больше, тем труднее собрать всех в одно время). Вынес для себя урок: как только агенда готова - сразу же ставить митинги.
Возвращаясь к целям командировки, одна из них всегда будет выполнена - посветить лицом (прости, господи). Личный контакт часто оказывается важнее всего остального, т.к. в конечном итоге люди работают с людьми, а не вендоры с заказчиками.