День 107. Как мне в американской компании

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

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

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

В дальнейшем, надеюсь, мои слова будут более обоснованы и мы совместными усилиями эти слабые места поборем.

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

1. Мусор в бэклоге

Наша очередь содержит около 1700 задач (все описаны за последние два года), из которых около трети неактуальны. В чем причина такой ситуации?

— отсутствует регулярный обзор бэклога
(у нас был лишь один product owner, у которого на это просто нет времени: каждый день только на митинги тратит полдня + переписка + текучка. Сейчас приняли еще двух сотрудников, к которым перейдет часть его функций)

— есть «зависшие» задачи
(Пример: задача была связана с нашим бывшим заказчиком, который ушел от нас, и теперь задача неактуальна. Или задачу описал бывший сотрудник компании, который уволился — и теперь его задачи почему-то не перешли на другого.
Причина: наиболее важные решения по продукту, в том числе и закрытие задач лежат на нашем американском офисе, а не на Ижевске. Соответственно, это тоже отслеживается и закрывается не всегда оперативно)

— много дублей
(причина кроется в том, что наша система представляет собой платформу с 3 модулями, которые можно использовать автономно. Эти решения уже давно живут самостоятельной жизнью, что приводит к тому, что команда, работающая над одним из модулей, с одной стороны, разрабатывает фичи, независимый от другого функционала, а с другой стороны, работает над задачами, которые могут быть тесно связаны с платформой. Таким образом, один и тот же баг (связанный, например, с каким-то платформенных косяком) может всплывать в разных модулях и находиться разными тестировщиками. Отслеживание подобных задач затруднено)

2. Слабый контроль за приоритетом

Наивысший приоритет у нас имеют Client Bugs, то есть ошибки, найденные самими клиентами и заказчиками. Критичные, например, мы вообще релизим в течение двух суток.

Однако с остальными задачами бывает неразбериха. С одной стороны, приоритет выставляется сразу автором задачи. С другой стороны, он может сильно отличается от видения product owner и у того не всегда есть время на обзор всех задач и приоритезацию бэклога.

Кроме того, на ежедневных митингах с product owner мы обсуждаем наиболее приоритетные задачи и не всегда они соответствуют тому, что стоит в Jira.

Другими словами, нет единого алгоритма приоритезации задач. Есть одна точка входа — наш product owner, но общение с ним, как правило затрагивает всего пару задач и не дает возможности отприоритезировать сразу весь бэклог

типа
— Hi! Should we take 111 in the next sprint?
— No, it's not urgent at all.
— Okay, but it has a critical priority in Jira. We don't have another important tasks
— Ow, you should do 291 tomorrow. It's very important
— We can't be in time. It is a laborious one
— Why haven't you start to implement it earlier?
— Cause it's minor!

3. Слабое документирование

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

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

Отсутствие коллективного владения информацией может выливаться в серьёзные проблемы.

А если какой-то сотрудник уволится? Вот так и возникают висячие задачи.

Договорились о чем-то по телефону? — Зафиксируй в Jira. Есть переписка — скопируй комментарием в Jira.

Тогда задачи будут иметь исчерпывающую историю и новому человеку будет проще влиться в процесс.

4.  Постановка задач

У нас сейчас достаточно много крупных задач, в которых принимает участие очень много смежных специалистов: дизайнер, фронтенд разработчик, бэкенд разработчик.

Например, задача называется «Multiwindows verification app» — нужно разработать многооконное приложение верификации. Мы таким не занимаемся) это я для примера придумал. Ну так вот. Как эта задача будет реализовываться?

Сначала команда посидит и подумает над концептуальным решением.

Потом, возможно, даст одному из сотрудников разработать прототип. Параллельно поставим задачу на дизайнера, который разработает дизайн.

После этого команда устроит демо, покажет прототип product owner и после его одобрения возьмет в работу, разделив разработку на BE и FE.

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

При этом у нас задача стоит на одном разработчике и отслеживать эти подзадачи достаточно проблематично.

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

В моем понимании задача (по концепции SMART) должна ставиться на одного человека и он должен иметь возможность ее выполнить самостоятельно.

То есть в приведенном примере было бы удобным эту задачу разделить на несколько мелких (разработка прототипа, разработка дизайна, развертывание тестового стенда, разработка фронтенда, разработка бэкенда), за которыми были бы закреплены соответствующие ответственные. В таком случае мы бы могли строить ИСР (иерархическую структуру работ), легко отслеживать подэтапы и анализировать критический путь.

5. Проектное управление

Сказанное выше вытекает в сложности проектного управления: мы пользуемся Jira, что является по сути workflow, а не системой управления проектами.

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

Правда, мы уже давно думаем над разработкой собственного инструмента для этих целей.

Возможно, ближайший инженерный день потратим на разработку прототипа, который все совместно и одобрим)

6. Отсутствие ресурс-менеджмента

У нас сильная команда и, возможно, это является причиной того, что какой-то серьёзный ресурс-менеджмент отсутствует.

Сводится он лишь к тому, что, планируя scope работ на очередной спринт мы учитываем рабочие дни разработчиков (т.е. возможные отпуска), а в отчетах для руководства считаем закрытые сторипойнты за неделю, динамику от спринта к спринту и КПД (отношение выполненных сторипойнтов к «идеально возможному»)

Учитывая то, что оценку задачи в сторипойнтах делает сама команда (а не архитектор, как на прежнем месте, что впрочем, тоже не лучший вариант), она может быть завышена. Это раз.

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

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

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

7. Не оцениваются индивидуальные показатели

Ещё об одном противоречии. Все команды, работающие на расширение функционала (в отличие от Канбана тех, что с Client bugs) у нас работают по SCRUM.

Сейчас многие команды используют скрам, даже если он имеет мало общего с тем, о чем писал Сазерленд)

В чем основные идеи SCRUM?

Что он подходит для СЛОЖИВШИХСЯ команд из кросспрофильных специалистов.

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

Да, ребята крутые, но малый срок «на баррикадах» мог и не дать им возможность обтереться, пройти сложности и стать одним целым.

SCRUM не предполагает индивидуальных оценок, но учитывая перечисленные трудности, мне было интересно отследить эффективность и динамику каждого разработчика.

Обнаружил удивительные вещи. Скорость разработки в пределах одной команды может отличаться до 3-4 раз. И такая тенденция сохраняется из спринта в спринт.

Отсутствие индивидуальных показателей и отчетов, возможно, не позволяло нам заметить это раньше, но теперь придётся задуматься, как мотивировать ребят и какие ещё показатели отслеживать.

8. А нужны ли метрики?

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

Нет общей burndown diagram, по которой видна динамика объёма бэклога (сколько задач команда выполняет и сколько приходит новых)

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

Не строим профиль ожидания, по которому видно, сколько в среднем фичи ждут реализации и «хвост» не актуальных задач.

Нет метрик для оценки дефектов релизов.

В общем, нет ничего того, что я с такой любовью и трепетом пытался вводить на прошлом месте.

Ну а зачем оценивать качество релизов и сравнивать их друг с другом, если ошибок у нас нет?

Помимо unit tests и ручного тестирования почти весь функционал (кроме совсем уж специфических кейсов) покрыт автотестами. При каждом pull request все тесты прогоняются автоматически и ни одна строчка кода не будет добавлена в релиз, если обнаружится малейшая проблема.

Да, можно сказать, что мы выпускаемых продукт совсем без багов. Заметьте: не пишем без багов. Их у нас не меньше чем у вас)) но мы их своевременно находим и исправляем до выпуска в прод.

И да, по поводу метрики. Пожалуй, самая главная метрика — довольный заказчик и бизнес, получающий прибыль. Если это есть — значит, мы все делаем правильно.

Обсудить у себя 0
Комментарии (0)
Чтобы комментировать надо зарегистрироваться или если вы уже регистрировались войти в свой аккаунт.

Войти через социальные сети:

Сахаров Денис
Сахаров Денис
сейчас на сайте
Читателей: 21 Опыт: 786.781 Карма: 6.74063
все 22 Мои друзья