Хочу поделиться интересными и полезными приемами в организации процессов компании в США. Я 9 лет работала в одной продуктовой компании, с момента окончания института, там было много хорошего, но мне с какого-то момента стало интересно «а как у других?». Примерно 8 месяцев назад мне постучался HR и позвал на собеседование в проектную компанию на позицию DBA для работы на компанию из США. В этот момент я работала на позиции заместителя технического директора. Такое предложение было довольно неожиданным, я не отнеслась к нему серьезно – посмотреть как у других хотелось, но не с таким резким снижением в карьере. Но, я согласилась прийти на собеседование – интересен был процесс.

Было 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 и ведущие разработчики.

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

Надеюсь, мой опыт будет вам полезен.

Автор:

Источник