[Из песочницы] 5 классных вещей в процессах американской компании
Было 3 этапа собеседования:
- С ведущим разработчиком проекта в компании-нанимателе
- С ведущим разработчиком из компании-заказчика (уже на английском)
- С архитектором в компании-заказчика
В процессе собеседования выяснилось, что компания очень крупная, разработка ведется с использованием тех же инструментов, что и в первой компании. Все очень близко. Много задач по базе данных. Мне понравилось насколько подробно выспрашивали о технологиях, видно было, что уровень специалистов высокий и проект интересный.
Я решила принять предложение и прийти в компанию — поработать над интересной задачей и посмотреть как организованы процессы в американской компании. Надо здесь оговориться, что у меня были розовые очки. Я считала, что если компания в Америке, то все процессы у нее внутри налажены, руководители работают по принципам Стивена Кови и Ицхака Адизеса. К моему удивлению, это оказалось не так. Розовые очки были сняты, но нашлось много полезного и нового в работе компании.
1. Scrum
Сама методология с ее плюсами и минусами заслуживает отдельной статьи. Пока только скажу, что разработка делится на «спринты». Каждый спринт 2 недели. Предполагается, что все задачи будут закрыты за этот срок. Если вдруг, кто-то быстрее справится со своими задачами на спринт, то он подключится и поможет тем, кто не успевает. Оценка сложности задачи, на мой взгляд, очень полезная штука, проводится коллективно. Есть созвон 1 раз в неделю, в течение которого команда обсуждает еще неоцененные задачи и присваивает сложность — на закрытом голосовании. Потом, когда все проголосовали, уже видно, кто и сколько поставил, если есть большие расхождения в оценке — люди, которые оценили задачу, высказываются и обсуждают. В итоге группа приходит к общей оценке задачи. Штука длительная (редко занимает меньше 2-х часов), но, на мой взгляд, полезная. Во-первых, все в курсе основных задач. Во-вторых, такой метод позволяет более объективно оценить сложность и объем задачи.
2. Demo для руководства каждый спринт
Не знаю, насколько часто встречается проблема, когда руководство компании не понимает, что делают программисты. В моей первой компании это был наболевший вопрос. Мы пробовали всякие отчеты, которые в итоге руководство не читало, в итоге вопрос повис, а непонимание осталось. А было такое простое решение. Презентация — раз в 2 недели (здесь по окончанию каждого спринта) с кратким обзором того, что было сделано понятным для бизнес-людей языком. Это дает руководству понимание, чем заняты люди и возможность понять туда ли движется проект.
3. All hands meeting
Вот это уже demo для сотрудников от руководства. С описанием основных приоритетов развития компании, достижений, и направления дальнейшего развития. На мой взгляд, замечательная штука. Она дает, во-первых, понимание людям какие задачи решает руководство и над чем оно работает. Во-вторых, это дает возможность соотнести свои приоритеты и принципы развития с приоритетами и принципами развития компании — так можно все время проверять, а по пути ли вам?
На таком «созвоне» обычно присутствует вся компания. И у всех есть возможность задать вопрос в эфире. Длится примерно 1 час. Проводится 1 раз в месяц или в квартал, в зависимости от компании.
4. Code review
Это больше техническая часть, но тоже очень полезная. Организация применения изменений в первой компании была следующая: разработчик вносил изменения, тестировал, отдавал тестировщику, затем следовала обязательная часть с подробным code review со стороны руководителя. Далее руководитель уже применял изменения к работающей системе. Мы не могли придумать как избавится от части с просмотром кода. А решение очень простое — code review должны делать сами разработчики. Только не тот, который писал код, а 2–3 других человека. Все их комментарии и замечания должны быть внимательно изучены и применены, либо автор-разработчик должен убедить своих коллег, что его решение лучше. Один момент — разработчики должны быть мотивированы делать code review. Иногда ожидание получения отзыва от других занимает столько же времени, сколько сама задача, а потом возвращаться к уже написанному коду и править его неудобно.
5. Bridge call во время проблемы
Если случается какая-то непредвиденная ситуация, например, загрузка ЦПУ на рабочем сервере возрастает до 90% и не удается в течение 5 минут устранить эту проблему, организуется Bridge call специалистов компании. Присутствуют DBA и ведущие разработчики.
Сначала я была довольно скептически настроена к таким «созвонам». Мне казалось, это должно скорее мешать решению проблемы. Однако я вижу эффективность этого метода — решение обычно находится и проблема разрешается. Такая совместная работа позволяет найти причину, благодаря тому, что несколько людей выдвигают предположения и занимаются поиском проблемы и ее решения.
Надеюсь, мой опыт будет вам полезен.
Комментарии (4)
22 июля 2016 в 14:22
+3↑
↓
Зам техдира не знает что такое scrum и удивляется демо?
Loengreen
22 июля 2016 в 15:06 (комментарий был изменён)
0↑
↓
Ну почему сразу не знает? Scrum скраму рознь. Многие просто не умеют его готовить. А demo во многих компаниях быстро превращается в формальность и умирает.
Вопрос в том, чтобы заставить все эти полезные штуки работать (и тогда в них поверят и к ним подключатся разработчики).
Автор как раз пишет про процессы и как они настроены в его новой компании.Автору: Спасибо, было интересно прочитать. Надо продолжать делать demo. :)
Помимо продолжительности, какие еще проблемы с покером планирования у вас были?
22 июля 2016 в 14:55
0↑
↓
А про минусы, пожалуйста
Nexiss
22 июля 2016 в 15:32
0↑
↓
Поддерживаю!
