Команда

В команде разработки много дисциплины, американцы всерьёз относятся к своему профессионализму. На стендапы в 8.45 никто ни разу не опоздал. Менеджмент и лиды часто отвечают в нерабочее время. При этом в 5 вечера всех как ветром сдуло. 

Большую роль играет фидбек от продактов и топов. Буквально говорят: "этой фичей вы сэкономили саппорту х часов работы = y денег". Команде не вливают "вы такие классные, спасибо", а показывают реальную пользу, которую они приносят. Это сильно мотивирует.

Токсичность и формализм напрочь отсутствуют. Ребята подкалывают друг друга, работать весело! Я однозначно не назову свою команду унылой, наверное, эти парни просто сидят на коксе 😆. Ощущается дух партнёрства, общей цели и вот этого всего. Большинство разработчиков пришли меньше полугода назад, но сколько в них смелости на ретроспективе! Напрямую говорят о проблемах, не замалчивают их, при этом оставаясь конструктивными. Красота. 

На 20 разработчиков приходится 0 тестировщиков. Роль QA исполняют эти же 20 человек. Команда практикует CD, и мануальное тестирование в нем присутствует. Каждый пулл реквест должен получить 3 апрува на код ревью. Эти же три человека проверяют фичу вручную. На эту активность закладывается 1 час в день при планировании. В среднем, откатываются раз в 3-4 месяца, что говорит о том, что подход работает (хотя я так и не понял как это возможно).

Вся команда - фулстек. Конечно, кто-то больше знает бек, кто-то фронт, но считается, что любую фичу может сделать в любой разработчик. А если не может - должен учиться. 

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

-----------------

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

Unit тесты

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

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

Плюсы:
- меньше регрессионных багов -> меньше времени на стабилизацию;
- более быстрый процесс поставки (первый шаг к CI\CD);
- проще дебажить код;
- улучшение архитектуры;

Минусы:
- написание тестов занимает время (0.3-0.9 от времени разработки, из того что я встречал);
- поддержка тестов занимает время (помимо исправления выломанной фичи, разработчик тратит время еще и на исправление тестов);
- написание тестов может попросту не оправдать себя. Некоторые проекты пишутся небольшими фазами, которые покупает клиент одну за одной. Команда не знает, сколько фаз продлится проект. Имея контракт только на 1 фазу, скажем, в два месяца, дешевле будет проверить функционал руками, чем писать тесты. Другой пример - прототипы, PoC.

Теперь можно прикинуть пару критериев, для ответа на вопрос "стоит ли писать тесты?":

- длительность проекта (если > 3-4K часов, то стоит писать);
- частота релизов и требования к поставкам (деплой раз в неделю без тестов может не взлететь);
- тип проекта (если много юая, и мало логики, возможно, авто тесты больше подойдут);
- контракт и прочие церковно-политические условия;

Как готовиться к командировке

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

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

- выслать план стейкхолдерам, наверняка им будет что добавить;

-сделать опросник для команды "что хотите обсудить с заказчиком?";

- положить агенду на вики и обновлять по ходу поездки. В будущем можно использовать в качестве отчета менеджменту или команде;

- пункт "провести ретроспективу \ получить фидбек" подходит практически к любой командировке;


Частой задачей командировок являются доп продажи. Продавать можно не только расширение текущих проектов (здесь что-то сложно советовать без контекста), но и новые. Рабочий вариант - изучить другие продукты компании (доступ в гит сильно упростит задачу), придумать фичи \ улучшения, предложить заказчику. 

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

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

Для очень серьёзных команд:

​ПМ аудит (чеклист скрам проекта)

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

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

Одна из практик, которая мне заходит, называется ПМ аудит. К джун\мидл ПМу раз в 2 месяца приходит сениор ПМ и проходится по всему проекту, выясняя что и как работает. Например: "расскажи как вы релизитесь" или "покажи статистику по автотестам". Опытный ПМ дает рекомендации, объясняет что и как можно улучшить, а на следующем аудите проверяет прогресс. Результат, конечно, кладется на вики 😀

По ссылке доступен чек-лист для скрам проектов (для каждого типа он свой), по которому проходит аудит: https://telegra.ph/Scrum-project-audit-checklist-03-10

Как разговаривать с мудаками

Сегодня порекомендую книгу "Как разговаривать с мудаками" Марка Гоулстона. Автор рассказывает о том, как вести себя с иррациональными людьми, разбирая примеры из практики. Многие из них отлично ложатся на управленческие сценарии.

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

Немного теории. В 60-х нейробиологи описали трехслойную модель мозга:

- Рептилоидный (хаха) - отвечающих за выживание, поиск еды, побег от опасности;
- Лимбический - эмоции: радость, ненависть, грусть, удовольствие;
- Неокортекс - планирование, оценка, контроль, логика;

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

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

Зачем ходить на конференции

...митапы, семинары, воркшопы и т.д.:

Знания - если опыта не очень много, то есть шанс услышать что-то новое для себя. Однако, после 2-3 конференций начинает казаться, что где-то я это уже слышал :)

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

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

​Декомпозиция задач

Неточные оценки - одна из причин задержки проектов. Когда разработчик говорит "будет готово через неделю" в большинстве случаев берет грех на душу (т.к. сделает быстрее или медленнее). Получая такую оценку, менеджеру остается только верить и молиться. Даже если разработчик боженька, хотелось бы иметь что-нибудь понадежнее веры, правда? В этом поможет декомпозиция.

Любую фичу можно разбить, абсолютно любую. Если говорят, что нельзя - лукавят. Цель менеджера - помочь команде раздробить фичу на мелкие задачи. Для этого существуют сессии планирования. Их ценность в том, что проговаривая фичу, зачастую обнаруживаются неочевидные нюансы, влияющие на длительность. Мысля категориями "неделя" при быстрой оценке, найти их гораздо сложнее.

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

Оптимальная длительность задачи при разбиении - 6-12 часов. Меньше - микроменеджмент и дорого обслуживать (создавать тикеты, обновлять статусы). Больше - риск недооценки.

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

Пример декомпозиции:

​Чек-лист оценки проекта, часть 2

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

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

​Jira для планирования

Недавно я выступал на митапе Agile team tools. Рассказывал как использовать джиру для операционного и стратегического планирования:

- спринтовые борды
- виджеты\фильтры
- интеграции других сервисов с джирой
- инструменты для тестеров и автоматизаторов
- оценки и статистику
- управление требованиями
- оптимизацию скорости команды и поиск узких мест

Это был мой первый опыт в качестве спикера и я волновался, как перед Страшным судом. Получилось вот так:

https://www.youtube.com/watch?v=qVze2m-FLOM&feature=youtu.be&t=45

Тут слайды.

​Что писать в контракте

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

По ссылке - важные пункты, которые можно вписать в fix price договор.

выгорание в 3 картинках

О работе менеджером

Первые два года работы ПМом я размышлял примерно так. Вот выучу джиру, MS Project, накоплю авторитета для программистов, по верхам въеду в техническую часть и все, менеджер от боженьки готов. На деле все оказалось несколько сложнее.

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

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

Из книжек мы можем понять общий вектор "хорошего менеджера", но не существует готовых рецептов как себя вести и что именно делать. Каждая управленческая задача уникальна и сильно зависит от деталей. Здесь поможет ментор. Раз в неделю встречаешься с гуру-ПМ, обсуждаешь что случилось и как лучше поступить. Он знает тебя, знает проект, многие детали и сможет дать дельный совет.

Я верю в универсальность менеджеров. То есть, хороший менеджер в ИТ может относительно легко стать хорошим менеджеров в строительстве. Да, надо шарить в бетоне, ГОСТах и так далее, но эту проблему можно решить подбором компетентной команды. Управленческие принцип работают везде одинаково. В конечном итоге, менеджер всегда отвечает за срок, бюджет и качество в той или иной форме.

​Картоха

Вот так выглядел бы наш мир, если вместо ИТ продуктов, мы бы с вами выращивали картошечку. Я из Беларуси, не смог пройти мимо такой блестящей аналогии.

​Вики лайфхаки

Проектную документацию надо где-то хранить. Если пользуетесь Jira, то наилучший инструмент для этого - Confluence. Поскольку это продукты одной компании Atlassian, интеграция между ними, как у пасхи с куличом.

Вот тут писал про структуру и страницы, которые полезно иметь, а сегодня скомпилировал наикрутейшие фичи для работы с контентом:
https://telegra.ph/Confluence-tools-06-02