Работа в банке. Часть 2. Процессы.

Все начинается с планирования. 

Первые этапы планирования начинаются еще в конце года, где верхнеуровнево накидываются планы на следующий год.

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

Стоит отметить вот что: 

• всего за год работы процесс квартального планирования менялся. Сперва при оценке задач использовали Planning poker (каждый участник команды оценивает задачу и потом сообща обсуждаем те оценки, которые выбиваются из общих), а потом просто перешли на ОК / НЕ ОК, когда каждый участник платформенной команды высказывается по понятным причинам. Как может тестировщик оценить сложно работы по фиче, например, на Android? Никак, потому сама эта идея курьезна.
• сперва мы работали по так называемому SAFE (по сути это замороченный Enterprise SCRUM), но потом все начали упрощать и что сейчас у нас сказать сложно. То ли не зашла эта замороченность всем, то ли не понятно. Типичный корпоративный срам.
• довольно много людей ушло, при чем с самых высоких позиций, что тоже отразилось на процессах. Видимо, что-то знали.

Далее, то что взяли на квартал разбиваем на спринты. Весьма условно, примерно. И тут начинаются нюансы. Иногда что-то влетает внезапное с бОльшим приоритетом. Условно, вы начали в прошлом квартале крупную фичу и планировали ее добить, но тут пришла внезапная хрень и вы делаете ее. Но проблема даже не в этом. Когда приходит внезапная хрень задачи очень часто не готовы. Ни с точки зрения аналитики, ни с точки зрения дизайна и бекенда. Вы берете в работу эту хрень, начинаете делать и потом постоянно что-то меняется походу. И вроде бы ничего такого, но доходит до того, что задача из условных двух-трех экранов, которую при должной проработанности можно сделать за неделю, делается 2-3 месяца. И это прискорбно.

Спринты. Длительность обычно неделя, иногда чуть дольше. Почему?

Со вторника-среды по следующие среду-четверг идет разработка, потом code freeze и регресс. В регрессе тестеры накидывают баги, которые в приоритете и каждая команда правит свои баги, но иногда баги правятся дольше, проблемы накапливаются и спринт идет дольше и соответственно релиз новой версии приложения откладывается. Регресс у нас вещь странная. Иногда почему-то мы правим баги, которые и не новые во все, а просто моча кому-то стукнула поправить его именно сейчас. Вообщем, название у этого этапа условное на мой взгляд. Ну и качество регрессов хромает в последнее время, ибо смоук-тестирование проходит поверхностное (людей мало и времени). А до этого была другая проблема - бесконечный регресс, который мог длиться неделю!!!! Вы неделю чисто правите баги, при чем опять же многие не из регресса. Хорошо, что эти времена ушли.

Стоит отметить, что у нас нет как такового беклога команды и работы с ним. Да, там лежат какие-то древние баги, которые некому из клиентов не упали и иногда они берутся в спринт, но все же это не то как хочется видеть работу над беклогом задач. Тут я сделаю ремарку, что возможно, только у нас так. Не знаю. 

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

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

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

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

Ну и, конечно, у нас есть утренний дейлик с типичной историей, где каждый высказывает, что делал вчера и что будет делать сегодня. На прошлой работе мы заменили подобный созвон статусом в слаке. Сейчас дейлик часто превращается в 30-60 минут разговоров, благо все еще по работе. 

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

Что еще плохо и влияет на процесс?

• Бекендеры часто либо низкой квалификации, либо ленивые жопы. То что можно сделать проще, делается сложнее. Ответы микросвервисов часто куски говна. Логика некоторая переносится на клиент, делая его толще, вместо того, чтобы делать тоньше. Всегда стоит стремиться к тонкому клиенту, особенно сейчас, когда могут быть проблемы с магазинами приложений и публикацией новых версий.  
• Была массовая текучка манагеров высоких позиций, в том числе тех дир, и даже несколько разрабов из мобильных гильдий. Даже product owner нашей команды покинул нас. Кажется, для банковской сферы текучка - это обычное дело.  
• Слабые коммуникации, особенно межкомандные.
• Бизнесу плевать на код. Главное пили новые рюшечки и карты. Тоже никакое не открытие, но часто это перерастает в снежный ком проблем, о которых поговорим в часте про кодовую базу.
• Устаревающая аналитика, либо слишком сумбурная. Приходится тратить много времени на выяснения вещей, на созвоны. А некоторые документы еще и писались теми, кто уже не работает. В этом плане самодокументируемый код - наше все, но как бы не у нас.
• Неравное распределение выполняемых задач. Наш стрим как будто делает чуть ли не 60-70% новых задач по проекту, при том, что команд довольно много. Внимание вопрос: что делают другие? А, точно, у нас же большая команда R&D и до сих пор Java-код местами. Хмм, а нахера? Но об этом в соответствующем посте.
• Бесполезные созвоны гильдии. Чаще всего это созвон в виде монолога одного человека (лида), где он рассказывает свое мнение на какие-то вопросы, проблемы или делится новостями. Польза от этого есть? Когда учитывают другие мнения - да, но происходит это не часто. Минус час вашего времени. Рассматривайте как время для обеда. Еще засыпаю хорошо под такие речи.
• Наверное, никого не удивлю, если отмечу, что к внештатным сотрудникам слабо прислушиваются и более того - у нас в Jira такие сотрудники выделены дополнительно. На встречах one to one с лидом, если такой сотрудник будет высказывать как улучшить проект, то к его мнению прислушаются слабо, даже если у человека опыта поболе, чем у лида. На самом деле обычная ситуация, но ребят по-своему жалко. Хотя стоит отметить, что лид у нас адекватный парень и не стоит над душой, контролируя каждый чих. Просто такая манера руководства видимо (решает только Core-команда).
• Нанимают иногда абы кого. Тут и кадровый дефицит всему виной, но все же не до такой же степени? Недавно собеседовали парня с годом опыта, 18 летнего, который не поступил еще даже в универ и не понятно будет ли поступать. И он всем понравился! Хотели было взять уже, но увы. В такой проект как наш я бы не рискнул брать таких ребят без менторства хотя бы полгода-год, а согласиться на такое явно некому не захочется. Иной раз на свои задачи времени не хватает.
• Тестерам нужно постоянно собирать сборку. А точнее, просто скинуть ссылку на собранную ветку. Почему не могут научиться самим эту ссылку доставать? Или как-то упростить для QA этот процесс. Иногда час-полтора в день уходит чисто на сборки. Не большая проблема, но все же не часто встречаемая, а значит легко решаемая.

Что стало лучше

• Созвонов при планировании вначале было значительно больше. Доходило до того, что целых два дня вы висели в зуме с командой. Сейчас пару звонков, иногда по паре часов. Прогресс. В других банках звонки по полдня - частая история, при чем каждодневная (поправьте, если ошибаюсь). 
• Какие-то подвижки в улучшении проекта и процессов есть. А главное, понимание на уровне руководства.
• У нас далеко не самые бюрократичные процессы. Какая никакая гибкость все же есть. Да, они все еще бюрократичны, но степень абсурда бывает гораздо выше в данной сфере. Хотя и у нас иногда хватает. Например, на запрос в поддержку по поводу доступа к аналитике мне так никто и не ответил. 
• Есть некая степень свободы у разрабов, но все равно вписана в 20% времени в неделю на технические задачки (ага, Гугл у нас)

Из общего впечатления о процессах я бы выделил вот что. Медлительность. Часто некомпетентность, лень и понимание, что теплое насиженное место лучше, чем попытка что-то менять, улучшать и развиваться. Боязнь сломать и быть виновным. Например, старые микросервисы, которые никто не хочет улучшать или перевести их на новые ответы. Все это делает изменения в проекте медленными и не очень гибкими, а главное значительно толще - жаль. 

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

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