Куда расти проджект менеджеру
Если отвечать за скоуп, бюджет и срок уже скучно, посмотрите каким еще менеджером можно стать:
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 часов, то стоит писать);
- частота релизов и требования к поставкам (деплой раз в неделю без тестов может не взлететь);
- тип проекта (если много юая, и мало логики, возможно, авто тесты больше подойдут);
- контракт и прочие церковно-политические условия;
Как готовиться к командировке
Первый вопрос, на который надо ответить - "а зачем вообще куда-то ехать?". Потусоваться в другой стране, конечно, прикольно, но, имея четкую цель, значительно проще достигнуть результата. Более того, командировки стоят денег и человек, который их платит, будь то заказчик или босс, должен хорошо понимать, что он получит взамен. Поэтому, главное, что нужно понять - для чего нужна поездка.
Когда цель ясна, можно формировать агенду. Набросайте вопросов, которые хотите решить, потом сгруппируйте, например так. Полезно:
- выслать план стейкхолдерам, наверняка им будет что добавить;
-сделать опросник для команды "что хотите обсудить с заказчиком?";
- положить агенду на вики и обновлять по ходу поездки. В будущем можно использовать в качестве отчета менеджменту или команде;
- пункт "провести ретроспективу \ получить фидбек" подходит практически к любой командировке;
Частой задачей командировок являются доп продажи. Продавать можно не только расширение текущих проектов (здесь что-то сложно советовать без контекста), но и новые. Рабочий вариант - изучить другие продукты компании (доступ в гит сильно упростит задачу), придумать фичи \ улучшения, предложить заказчику.
Главной ошибкой, которую я совершил было не запланировать встречи заранее. Подумал, что сделаю это на месте, но не учел, что у людей уже были планы. Из-за этого не смог решить несколько вопросов, требовавших участия большого количества стейкхолдеров (а чем их больше, тем труднее собрать всех в одно время). Вынес для себя урок: как только агенда готова - сразу же ставить митинги.
Возвращаясь к целям командировки, одна из них всегда будет выполнена - посветить лицом (прости, господи). Личный контакт часто оказывается важнее всего остального, т.к. в конечном итоге люди работают с людьми, а не вендоры с заказчиками.
Первый вопрос, на который надо ответить - "а зачем вообще куда-то ехать?". Потусоваться в другой стране, конечно, прикольно, но, имея четкую цель, значительно проще достигнуть результата. Более того, командировки стоят денег и человек, который их платит, будь то заказчик или босс, должен хорошо понимать, что он получит взамен. Поэтому, главное, что нужно понять - для чего нужна поездка.
Когда цель ясна, можно формировать агенду. Набросайте вопросов, которые хотите решить, потом сгруппируйте, например так. Полезно:
- выслать план стейкхолдерам, наверняка им будет что добавить;
-сделать опросник для команды "что хотите обсудить с заказчиком?";
- положить агенду на вики и обновлять по ходу поездки. В будущем можно использовать в качестве отчета менеджменту или команде;
- пункт "провести ретроспективу \ получить фидбек" подходит практически к любой командировке;
Частой задачей командировок являются доп продажи. Продавать можно не только расширение текущих проектов (здесь что-то сложно советовать без контекста), но и новые. Рабочий вариант - изучить другие продукты компании (доступ в гит сильно упростит задачу), придумать фичи \ улучшения, предложить заказчику.
Главной ошибкой, которую я совершил было не запланировать встречи заранее. Подумал, что сделаю это на месте, но не учел, что у людей уже были планы. Из-за этого не смог решить несколько вопросов, требовавших участия большого количества стейкхолдеров (а чем их больше, тем труднее собрать всех в одно время). Вынес для себя урок: как только агенда готова - сразу же ставить митинги.
Возвращаясь к целям командировки, одна из них всегда будет выполнена - посветить лицом (прости, господи). Личный контакт часто оказывается важнее всего остального, т.к. в конечном итоге люди работают с людьми, а не вендоры с заказчиками.
ПМ аудит (чеклист скрам проекта)
2,5 года назад я пришел на собеседование в свою текущую компанию. Меня подкупили процессы - у всех аспектов разработки есть свои гайдлайны, каждому ПМу выделяют деливери менеджера, который не даст запороть проект, и ментора, помогающего прокачиваться.
Все процессы задокументированы на вики. Для любого действия есть страничка, где написано что и как делать. Это как кулинарная книга с рецептами - открыл, посмотрел, "ага, вот это еще нужно добавить". Разумеется, никакие процессы не покроют все проектные ситуации, но в большинстве случаев это очень удобно.
Одна из практик, которая мне заходит, называется ПМ аудит. К джун\мидл ПМу раз в 2 месяца приходит сениор ПМ и проходится по всему проекту, выясняя что и как работает. Например: "расскажи как вы релизитесь" или "покажи статистику по автотестам". Опытный ПМ дает рекомендации, объясняет что и как можно улучшить, а на следующем аудите проверяет прогресс. Результат, конечно, кладется на вики 😀
По ссылке доступен чек-лист для скрам проектов (для каждого типа он свой), по которому проходит аудит: https://telegra.ph/Scrum-project-audit-checklist-03-10
2,5 года назад я пришел на собеседование в свою текущую компанию. Меня подкупили процессы - у всех аспектов разработки есть свои гайдлайны, каждому ПМу выделяют деливери менеджера, который не даст запороть проект, и ментора, помогающего прокачиваться.
Все процессы задокументированы на вики. Для любого действия есть страничка, где написано что и как делать. Это как кулинарная книга с рецептами - открыл, посмотрел, "ага, вот это еще нужно добавить". Разумеется, никакие процессы не покроют все проектные ситуации, но в большинстве случаев это очень удобно.
Одна из практик, которая мне заходит, называется ПМ аудит. К джун\мидл ПМу раз в 2 месяца приходит сениор ПМ и проходится по всему проекту, выясняя что и как работает. Например: "расскажи как вы релизитесь" или "покажи статистику по автотестам". Опытный ПМ дает рекомендации, объясняет что и как можно улучшить, а на следующем аудите проверяет прогресс. Результат, конечно, кладется на вики 😀
По ссылке доступен чек-лист для скрам проектов (для каждого типа он свой), по которому проходит аудит: https://telegra.ph/Scrum-project-audit-checklist-03-10
Telegraph
Scrum project audit checklist
Below are some management best practices we use at Oxagile when implementing Scrum projects. Following these doesn't guarantee one wouldn't ever lose the game. Unexpected circumstances, we could not influence, happens daily. Still struggling them is a part…
Как разговаривать с мудаками
Сегодня порекомендую книгу "Как разговаривать с мудаками" Марка Гоулстона. Автор рассказывает о том, как вести себя с иррациональными людьми, разбирая примеры из практики. Многие из них отлично ложатся на управленческие сценарии.
Кроме отношений с коллегами, рассматривают отношения с родителями, детьми, партнером, людьми, с психическими расстройствами и даже потенциальными самоубийцами.
Немного теории. В 60-х нейробиологи описали трехслойную модель мозга:
- Рептилоидный (хаха) - отвечающих за выживание, поиск еды, побег от опасности;
- Лимбический - эмоции: радость, ненависть, грусть, удовольствие;
- Неокортекс - планирование, оценка, контроль, логика;
Все три слоя присутствую в каждом из нас с рождения, а связи между ними развиваются особенно интенсивно в детстве. Чем сильнее дисбаланс в работе трех уровней, там проще человек теряет связь с реальностью и ведет себя иррационально, и наоборот.
В большей степени, нами управляет лишь один уровень мозга в конкретный момент времени. Задача рационального человека понять какой уровень мозга управляет бытовым психом прямо сейчас, "спуститься" и поговорить с ним на этом уровене. Т.е. нельзя погасить истерику с помощью логических рассуждений и фактов. Чтобы урезонить психа, нужно рассуждать как псих, сочувствовать, погружаться в его проблему и постепенно активируя более высокие уровни мозга.
Сегодня порекомендую книгу "Как разговаривать с мудаками" Марка Гоулстона. Автор рассказывает о том, как вести себя с иррациональными людьми, разбирая примеры из практики. Многие из них отлично ложатся на управленческие сценарии.
Кроме отношений с коллегами, рассматривают отношения с родителями, детьми, партнером, людьми, с психическими расстройствами и даже потенциальными самоубийцами.
Немного теории. В 60-х нейробиологи описали трехслойную модель мозга:
- Рептилоидный (хаха) - отвечающих за выживание, поиск еды, побег от опасности;
- Лимбический - эмоции: радость, ненависть, грусть, удовольствие;
- Неокортекс - планирование, оценка, контроль, логика;
Все три слоя присутствую в каждом из нас с рождения, а связи между ними развиваются особенно интенсивно в детстве. Чем сильнее дисбаланс в работе трех уровней, там проще человек теряет связь с реальностью и ведет себя иррационально, и наоборот.
В большей степени, нами управляет лишь один уровень мозга в конкретный момент времени. Задача рационального человека понять какой уровень мозга управляет бытовым психом прямо сейчас, "спуститься" и поговорить с ним на этом уровене. Т.е. нельзя погасить истерику с помощью логических рассуждений и фактов. Чтобы урезонить психа, нужно рассуждать как псих, сочувствовать, погружаться в его проблему и постепенно активируя более высокие уровни мозга.
Зачем ходить на конференции
...митапы, семинары, воркшопы и т.д.:
Знания - если опыта не очень много, то есть шанс услышать что-то новое для себя. Однако, после 2-3 конференций начинает казаться, что где-то я это уже слышал :)
Нетворкинг - это самая полезная часть таких событий. Знакомишься с новыми людьми, заводишь полезные контакты, узнаешь ситуацию в индустрии из первых рук. Многим (окей, мне) сложно вывести себя из зоны комфорта и заговорить с незнакомым человеком. В таком случае можно задавать вопрос спикерам - они по определению готовы давать ответы. Посмотрите на ивент, как на место решение вашей проблемы, консультацию у крутых специалистов.
Вдохновение и идеи - выхваченные из контекста фразы, давно известные истины, сказанные другим языком, гарантировано натолкнут на желание попробовать что-то новое. Энергично возвращаешься на работу с мотивацией поскорее это новое опробовать. Уважаемые работодатели, вот ради чего стоит оплачивать сотрудникам обучение!
...митапы, семинары, воркшопы и т.д.:
Знания - если опыта не очень много, то есть шанс услышать что-то новое для себя. Однако, после 2-3 конференций начинает казаться, что где-то я это уже слышал :)
Нетворкинг - это самая полезная часть таких событий. Знакомишься с новыми людьми, заводишь полезные контакты, узнаешь ситуацию в индустрии из первых рук. Многим (окей, мне) сложно вывести себя из зоны комфорта и заговорить с незнакомым человеком. В таком случае можно задавать вопрос спикерам - они по определению готовы давать ответы. Посмотрите на ивент, как на место решение вашей проблемы, консультацию у крутых специалистов.
Вдохновение и идеи - выхваченные из контекста фразы, давно известные истины, сказанные другим языком, гарантировано натолкнут на желание попробовать что-то новое. Энергично возвращаешься на работу с мотивацией поскорее это новое опробовать. Уважаемые работодатели, вот ради чего стоит оплачивать сотрудникам обучение!