Интервью с Женей Старчак. Жизнь без аналитиков глазами менеджера.
Жень, привет! Спасибо что согласился на интервью!
В прошлые наши беседы ты рассказывал, что у вас в компании политика — делаем продукты без бизнес и системных аналитиков. Ничего не перепутала? Как вы дошли до такой жизни?
Привет! Да, ничего не перепутала :)
Есть несколько причин.
Во-первых, проекты отличаются следующими свойствами:
- они короткие по времени;
- они выполняются небольшой командой, и команда может держать контекст задачи самостоятельно;
- заказчик кровно заинтересован в успешном завершении проекта, поэтому быстро готов отвечать на вопросы и обсуждать предлагаемые варианты.
По сути, это часть необходимых условий, которые нужны для использования гибких методологий.
Во-вторых, проект живет ограниченное время - через 2-3 года проект проще переписать заново, чем вносить изменения: так как поменяются технологии, часть нефункциональных требований или новые задачи заказчика потребуют внести доработки, по трудоемкости сопоставимые с реализацией проекта заново.
Ну и в-третьих, команда разработки обладает набором навыков и компетенций для реализации подобных проектов.
2 - 3 года? Т.е. такие долгожители, как ваша почта, поисковик, новости, погода и так далее переписываются периодически с нуля?
Нет, там немного другое. Там продукты, которые состоят из кучи проектов.
У поиска за 3 года очень сильно меняется архитектура, например, и технологии внутри.
У нас проще написать заново через 2 года, чем делать крупную доработку.
Понятно, что переписывается не совсем все, но существенный слой бизнес логики может поменяться полностью через 2-3 года
Ты имеешь в виду свои проекты? Можешь вкратце рассказать их суть?
Это агрегаты для построения финансовой отчётности, регулярные расчёты вознаграждения, поставка данных из учётных систем в хранилище данных.
Т.е. инфраструктура для других продуктов?
Скорее унификация (не люблю это слово, но попроще подобрать не получается) данных о продажах продуктов для финансистов, часть регулярных расчетов и предоставление наших данных аналитикам сервисов (тем людям, которые готовят финансовую отчётность, и строят финансовые модели)
Правильно понимаю, что заказчик=пользователи внутренний? Cколько лет существует система?
Пользователи внутренние, но они с помощью результатов проекта общаются с внешним миром и строят модели.
Проекту в текущей инкарнации около 5 лет.
Т.е. фактически заказчик выступает аналитиком? Кто выполняет роль сбора информации от заказчика и трансляцию на уровень разработчиков? Оценивает непротиворечивость требований?
Заказчик выступает очень мотивированными пользователем результата работы системы. Если заказчик не расскажет нам все про свою работу, то ему придется считать все вручную. Это скорее всего нереалистичная задача.
В роли аналитика выступает тимлид разработки и менеджер проекта. То есть менеджер общается с заказчиком, оценивает из своего понимания задачи и того, каким образом реализована система. Потом тимлид может задать доп. вопросы, или менеджер с тимлидом пообщаются вместе с пользователями и решат как будет сделано.
Бывают ли случаи, что на выходе получаете расхождения между ожиданиями заказчика и реализацией?
Так как с заказчиком команда работает уже давно (и заказчик команду знает, и команда заказчика), то реализация в большей степени устраивает заказчика. Но жизнь всегда интересна и многогранна, и даже при таком подходе всегда есть случаи, когда в реальном мире есть новые сюжеты и новые сценарии, про которые забыли рассказать во время разработки и сбора требований.
Про мотивированного заказчика звучит очень круто. Видимо, у вас офигенная команда и доверие на всех уровнях.
Тебе как менеджеру удобна такая модель? Ты и документируешь требования?
Насколько можем - да, успеваем документировать. Не очень подробно, скорее как справочная информация "а что мы тут такого сделали".
Модель удобная для небольшой команды с низкой текучкой, когда все в контексте. Но погружать нового человека в контекст иногда бывает чуть сложнее.
Успеваешь с основными обязанностями? Часто переработки?
По обязанностям - как и везде, большей частью успеваем, иногда бывают завалы. Переработки - как и у всех, кто работает в проектах с финансистами - то густо, то не очень :)
Согласна, от этого не уйти :)
Сколько ты в среднем даешь времени новым членам команды на погружение ? Как выстроен процесс передачи знаний?
Процесс для передачи знаний у нас классический, ничего нового. Любимая бразильская система - даем задачу, даем время с небольшим запасом и по ходу решения задачи отвечаем на все (совсем все) вопросы, которые возникают у разработчика. Обычно за месяц - полтора человек знакомится с проектом и докатывает первую задачу до прода.
А кто занимается тестированием и на основании чего определяется acceptance criteria?
У нас есть выделенный тестировщик на некоторых задачах. Критерии приемки - соответствие задачи входному описанию, на сложных вопросах у меня спрашивают, как делаем, так или по-другому. Большей частью уточняем у заказчика, какой вариант будет более подходящим, не дожидаясь сдачи или демонстрации.
Звучит как очень динамичный процесс и требующий проактивности от всей команды. Скажи, у тебя есть обязательные требования к личным качествам кандидатов?
У нас ребята очень разные, но, наверное, их объединяет одно - они постоянно учатся и увлечены программированием, новыми технологиями. Поэтому мы очень часто готовы к серьезным техническим изменениям.
А ты продолжаешь развиваться как аналитик или больше погружаешься в ремесло менеджера продукта?
Развиваться нужно всегда - soft skills и hard skills. Hard skills правда больше технические. Например, нужно собрать метрики со своего проекта, или поработать с данными - знаний всегда не хватает, а данные хочется получить как можно быстрее.
Уклончиво)))
Тут сложно сказать - скажем, питон - это явно не скилл для аналитика :)
и явно не менеджерский :)
Эт точно))
А без него большей частью никуда - как еще можно сверить разные источники данных или связать несколько экселек :)
Ты изучит питон? А какие еще скиллы?
Я скорее в начале пути питониста :) из hard skills время уходит на python + pandas, sql, внутренние технологии (типа самописных map reduce кластеров).
Из soft skills- нужно работать с людьми в первую очередь.
Ну и оценивать задачи, планировать, управлять рисками, искать риски и проблемы, которые помешают закончить задачи вовремя.
Все-таки у нас есть странный тип задач - задачи с жестким дедлайном (если задача не сделана к дате - расчехляй калькулятор и считай сам. Если сделана с багами - будь готов быстро разобрать баги с прода сам)
"Из soft skills- нужно работать с людьми в первую очередь."
— давай эту тему подробнее отдельно обсудим. Не возражаешь?
Нет :) Люди - это основная ценность:)
Получилось очень интересное интервью. Спасибо большое за подробные ответы!
Заключительный вопрос, чтобы подвести итоги. Как ты оцениваешь подход к разработке без роли аналитика?
Роль все равно остается, просто эту роль приходится выполнять не отдельному человеку, а нескольким людям, каждому в какой-то мере.
Поэтому если команда маленькая, заказчик доступен, быстро отвечает на вопросы и не уходит от ответственности, и получается конструктивно и быстро проговаривать задачи - то так работать можно, и это может работать.
Если команда растет, менеджер тратит на общение с внешним миром все доступное время - нужен источник знаний, который смотрит на задачу не со стороны кода, а со стороны потребностей. Обычно это аналитик :)
