Эволюция подхода к производству в AGIMA за 15 лет

Не так давно компании AGIMA исполнилось 15 лет, и скоро мы будем отмечать это событие с соответствующим размахом: соберем 1000 айтишников, чтобы отпраздновать. Поэтому для тех, кто устал от онлайна — велкам в офлайн. А я начну свой рассказ.  Хочется немного вспомнить, как эволюционировал подход к производству в нашей компании за эти годы.

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

c18a2ddf3b9f3fef0a679744032993af.jpg

Прекрасное далеко

Когда я только пришел в компанию в 2011 году старшим PHP-разработчиком, у нас был небольшой отдел «веб-мастеров» (которые и в верстку, и в разработку), парочка проектов на Битрикс, еще несколько на самописной CMS и странный таск-трекер.

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

Еще я до сих пор помню забавный случай на одном собеседовании, когда соискатель в ответ на вопрос «С какими таск-трекерами вы работали?» сказал: «Все задачи ставлю через скайп». Мы тогда от души посмеялись, но теперь, оглядываясь назад, я понимаю, что на тот момент мы и сами были недалеки от этого. Да, задачи были в трекере, но знания были не пойми где: в почте, в скайпе, в лучшем случае — на сетевом диске.

Учет велся, что называется, «по кассе», в куче разных Excel-файлов, а планирование представляло собой обсуждение на словах и записи в блокнотах.

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

Да, у нас тогда еще существовали классические «продажники» и «производственники», между которыми было достаточно шаткое равновесие. Еще был отдел техподдержки, равновесия в котором вообще не было :) Руководители проектных офисов у нас назывались «аккаунт-директоры», а руководители проектов — «менеджерами».

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

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

Наведение порядка в финансовом учете

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

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

Master-Excel / finplan

Первым большим изменением, с которым нам на первых порах очень помогли наши друзья из Команда-А, стало введение «Мастер-Excel» (finplan), где хранилась вся информация по проектам: клиент, проект, дата завершения работ, дата выставления акта/счета, суммы, какой специалист выполняет работы и прочее.

Бизнес-процесс по актуализации finplan у нас выглядел прикольно:

  • каждому менеджеру распечатывали выгрузку с данными по его проектам;

  • менеджеры тратили полдня на то, чтобы отметить все изменения вручную;

  • их руководитель проверял эти изменения;

  • потом эти распечатки сдавали в финотдел;

  • Вика Бакума тратила еще день, чтобы всё это внести в наш Большой Excel;

  • Саша смотрел на данные и срезался на основе этих данных по ключевым позициям: продажи, производство, проекты, получение денег и т. д.;

  • потом печатные версии заменили на версии «по почте», но принцип остался тот же.

image-loader.svg

Отгрузки и обязательства

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

Тем не менее мы еще долгое время прожили с какой-то странной гибридной системой, когда доходы мы считали по актам (по обязательствам), а расходы — по «кассе». Оглядываясь назад, понимаем, что это выглядит как какая-то дичь, но тогда это был весьма себе прикольный инструмент, чтобы управлять рентабельностью в моменте. (Месяц вышел плохим? Не проблема, перенесем какие-то выплаты на первое число следующего месяца — и всё ок!)

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

Рабочий PNL и диджитализация

В конечном итоге у нас всё устаканилось, и мы начали планироваться по актам как в доходной части, так и в расходной. Появился полноценный PNL, который был общий по компании и отдельный для наших производственных отделов, и куча полезных сводных: по кэш-флоу, по дебиторке, по «отгрузкам» (т. е. в какой месяц сколько работ мы закроем так, чтобы у клиента возникли обязательства) в конкретный месяц или квартал и в разрезах по отделам, аккаунт-директорам, специалистам и т. д.

Через какое-то время мы наконец-то перевели все эти данные в онлайн, допилив под себя 1С-Битрикс. Теперь все данные в нее вносились асинхронно, согласования происходили там же, но часть сотрудников возмущалась «сырости» и неудобству функционала («В эксель хоть изменения протянуть можно! По одной строке вносить неудобно!») и требовала оставить всё как было и «не выдумывать». Со временем мы нарастили функционал, появились групповые изменения, «протягивания», история изменений и прочее. Я сомневаюсь, что сейчас кто-то согласился бы вернуть всё «как было», но тогда сопротивление было достаточно сильное.

image-loader.svg

Цеха, проектные офисы, упразднение отделов продаж и ТП

Цеха — производственные отделы

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

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

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

С ростом объемов внутри цехов у нас появились и свои подцеха со своими руководителями: т.е. внутри цеха разработки есть еще цеха PHP, Java, Mobile, Python/Go и другие, а в цехе проектирования — системной аналитики, проектирования интерфейсов и так далее.

Аккаунтские группы / Проектные офисы

Отдел менеджмента разделили на несколько аккаунтских групп (в дальнейшем — проектные офисы). Во главе каждой встал свой руководитель (аккаунт-директор или, позже, руководитель проектного офиса). У каждой группы был свой портфель клиентов, сотрудники и свои планы по объемам. 

Это позволило сильно пробустить наш рост: теперь он не ограничивался пропускной способностью Одного Главного Менеджера, а зависел от нескольких аккаунт-директоров. Каждый из них работал над своим планом по объемам, и если у одного что-то не получалось, то другие могли это компенсировать.

Схема также получалась более отказоустойчивой: в случае увольнения аккаунт-директора всегда можно было перепоручить клиента кому-то еще. Или если эскалаций от клиента было много, а АД с этим не справлялся, Саша / Женя Лобанов / Сергей Кожемякин могли в ручном режиме «забрать» клиента у одного АД и отдать другому. Это обычно была самая крайняя мера, и на моей памяти до нее доходило всего пару раз.

Со временем мы поняли, что, чтобы сохранять динамику быстрого роста, нам нужны новые проектные офисы. Поначалу мы все пытались нанять крутых ребят со стороны, которые смогли бы сформировать новый проектный офис, но по результатам нескольких лет экспериментов мы поняли, что прежде, чем стать РПО, человек должен впитать нашу ДНК. Внутренний рост из РП в групп-хеда, а затем в РПО показал себя замечательно, у нас так родилось уже более 5-ти новых проектных офисов. 

Кстати, какое-то время в компании жили вместе забавные аббревиатуры: АД и РПЦ — Руководитель Подразделения Цеха :)

Отдел продаж и сами продажи

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

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

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

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

Техподдержки больше нет

Изначально у нас было два отдела по обслуживанию клиентов: «Производство» (новые проекты) и «Техподдержка» (кстати, лендинг почему-то до сих пор жив :) Какое-то время это была рабочая схема: абонементы по техподдержке позволяли нам получать гарантированные объемы, а выделение этой услуги в отдельный «юнит» давало немного отстроится от конкурентов, у которых такой услуги в явном виде не было.

Проблемы с этой схемой тоже были:

  • Было не совсем понятно, как делить ресурсы между «Производством» и «Техподдержкой»: с одной стороны, лучшие специалисты нужны были на самых сложных участках (новые проекты), а с другой — нельзя было оказывать плохой сервис нашим постоянным клиентам, ведь они залог нашей стабильности.

  • Еще сложнее было делить «большие» работы внутри одного клиента: вроде он на техподдержке, но хочет реализовать с нами еще один проект — и в результате клиенту приходилось работать с двумя командами параллельно.

  • Специалисты также частенько «горели» от того, что «сидели на техподдержке» и занимались багами, в то время как душа требовала «серьезных вызовов», а не копаться в старом legacy, поправляя очередную JavaScript-карусель и т. д.

В новой схеме не нашлось места и техподдержке: теперь каждый проектный офис вел своего клиента от пресейла до конца его LTV. 

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

Когда контракты подходили к концу, мы их просто не продляли, и со временем отдел органически прекратил свое существование.

Рентабельность во всем и «усреднение» финансовых мотиваций

image-loader.svg

Про рентабельность стали думать практически все, и это было очень воодушевляюще. Почти каждый из тогдашних руководителей стал своего рода минипредпринимателем: со своими отгрузками, затратами, ФОТом, прибылью и премиями в виде процентов от этой прибыли.

Чтобы наметить какую-то первую цель, Саша установил нам, руководителям, первую планку в 10% рентабельности по итогам квартала, назначил премии в случае победы, и мы начали активно работать в этом направлении.

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

Вместе с этим кейсом пришло понимание, что финмотивация у всей компании должна работать не поквартально, а каждый месяц, чтобы исключить ситуацию, когда в первый месяц никто особо не напрягается («впереди еще два месяца, наверстаю!»), во второй начинают вовлекаться, а в последний месяц квартала всеми правдами и неправдами стараются закрыть побольше работ, чтобы выполнить план. Такой подход приводил к синусоидоподобному графику объемов и был ущербным, мы его быстро заменили. В результате мотивация у всех причастных стала учитывать средние показатели за последние три месяца, и график стал более плавным.

Всё это стало офигенным фундаментом для нашего дальнейшего развития, мы стали работать над «утечками» рентабельности, стали явно видеть, когда не хватает объемов или когда затраты превышают прогнозные. Параллельно мы повышали планку рентабельности из года в год и каждый раз сталкивались с собственным сопротивлением. Казалось, что выжать еще 5% вдобавок к текущему показателю просто невозможно. Но каждый раз мы с этим успешно справлялись, и это было круто, ведь обычно при масштабировании рентабельность снижается. Но мы доказали, что возможно и обратное.

Планирование специалистов

Трудности роста

С ростом объемов всё тяжелее становилось планировать распределение специалистов по проектам, и мне как молодому руководителю всё хуже удавалось уместить всё это в своей голове.

Первый мой подход был достаточно забавный:

image-loader.svgimage-loader.svg

Общий Гантт по всем проектам

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

С наличием общего Гантта по всем проектам компании планировать стало проще, но появилось и много лишних телодвижений:

  • РП нужно было вносить данные в еще одну систему;

  • руководителям отделов нужно было отсматривать ее;

  • учет в компании (finplan и «отгрузки») иногда расходился с Ганттом, и приходилось прояснять информацию в ручном режиме;

  • помимо запланированного времени (которое можно было увидеть в Гантте), нужно было еще разобраться, что там с рентабельностью (а для этого сходить в finplan и еще в таблицу с зарплатами и как-то смэтчить одно с другим).

Планирование через finplan

Ожидаемо такой подход с ростом объемов тоже начал трещать по швам, и мы его реформировали: РП заносили все данные в finplan, и цеха начали планироваться исключительно по нему. Это было удобно, потому что сразу позволяло понять, когда проект начинается, какой там тип работ и бюджет. А еще позволило нам строить простые сводные, по которым мы понимали, кто из специалистов недогружен, а у кого наоборот перебор. Например:

Красные квадратики означают «беду», желтые — «внимание», а зеленые — «всё в порядке».Красные квадратики означают «беду», желтые — «внимание», а зеленые — «всё в порядке».

Аналогичная система работала и по другим ролям: тимлидам, РП и т. д.

Такие сводные работают у нас по сей день, хотя с ростом проектов необходимость в них практически отпала: как правило, сейчас у нас команды закрепляются за проектом на условно-бессрочный период, и мы следим за рентабельностью всего проекта, где каждая команда (РП и ТЛ), в свою очередь, следят за рентабельностью конкретных участков.

Нам нужны тимлиды!

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

Тогда мы ввели роль тимлидов, которые стали отвечать за всё происходящее с их проектом, формировать под себя команды и разделять ответственность за успех или провал с нашими РП.

Размытие ответственности

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

В первом подходе мы сказали так: ТЛ отвечает за всё «производство» в разработке и за трудозатраты с рентабельностью, а РП — за объемы и сроки. Это создало систему сдержек и противовесов, когда ТЛ топил за рентабельность, а РП — за то, чтобы сделать побольше и побыстрее. Качество же было где-то между.

С одной стороны, мы декларировали, что тимлид отвечает за всё производство, а с другой — они не обладали достаточными навыками, чтобы полноценно менеджерить всё это производство. Некоторые руководители проектов стали рассматривать работу с тимлидом как работу с «черным ящиком»: закидываю в него смету, ТЗ и тайминги — дальше пусть сам разбирается, как всё сделать в срок, моя хата с краю.

Какое-то время мы пытались наладить процессы и сделать из тимлидов бОльших менеджеров, чем они были на самом деле, научить разным РПшным премудростям и выстроить схему так, чтобы они действительно могли дублировать функцию руководителя проекта на своем участке. Я даже подумывал о том, чтобы набрать себе в отдел своих руководителей проектов. Границы ответственности размывались, люди не понимали, кто за что отвечает: кто должен строить Гантта или срезаться по успеваемости, может ли РП влиять на выбор исполнителя, должен ли тимлид напрямую общаться с клиентом без РП и т. д.

Мы часто спорили с руководителями отделов, на чьей стороне косяк, вместо того чтобы договариваться о том, как сделать проект вовремя. Мои тимлиды в гневе уходили из офиса проветриться после очередной ссоры с РП, градус напряжения рос. И у нас появились своего рода «касты»: тимлиды часто не любили менеджеров, те отвечали им взаимностью, эскалации и арбитраж были ежедневной рутиной, а не чем-то из ряда вон.

Сделаем матрицу ответственности!

В это время одной из наших неудачных попыток наладить работу стало желание свести все активности ТЛ и РП в некую «матрицу ответственности» (или, как теперь стало модно ее называть, RACI), где было бы четко видно, кто за что отвечает. Подразумевалось, что если мы всё жестко регламентируем, то людям просто станет не о чем спорить. Просматривая историю изменений, я вижу, что в ней было больше сотни апдейтов разного размера, но ни в какой момент времени она не позволяла нам абсолютно исключить конфликты или проблемы, возникающие на стыке ролей.

image-loader.svg

Составление матрицы осложнялось человеческим фактором и тем, что проект у нас был не один, а матрицу мы пытались построить универсальную. На каком-то проекте очень нужна была именно техническая компетенция ТЛ, и мы подбирали туда человека с прокаченными hard skills, но без опыта управления командой (РП прикрывал его на этом поле). Тот же человек на другом проекте оказывался некомпетентен, и наоборот. 

Проекты разные, и команды под них формируются разные (где-то первую скрипку будет играть ТЛ, а где-то — РП). Поэтому мы снесли эту матрицу ответственности и стали выстраивать командную работу: синхронизировали системы мотивации (теперь обе роли были мотивированы на рентабельность, сроки и объемы), на уровне руководителей стали общаться с РП и ТЛ как с единым целым, стали порицать деления на «касты» и перекидывание ответственности. Вместо этого направляли людей на конструктивный диалог и постоянно объясняли им, что у них одна цель и работать над ней им надо вместе. Со временем проблема противоборств ушла, наши команды стали жить в гармонии, а эскалации стали исключениями из правил.

Финансовая мотивация у технарей?!

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

Помимо прочего, это позволило нам больше вовлечь тимлидов в решение задачи, как сделать проект рентабельно, вместо того чтобы об этом думал кто-то другой (РП или руководитель). Еще это исключило потенциальное поле для конфликтов, когда ТЛ хочет всё переписать с нуля, а руководитель ему это запрещает, потому что у него «бюджет». 

В развитие тимлидов мы вообще всегда вкладывались очень много: проводили обучающие встречи, отправляли на курсы или конференции, организовывали различные активности (например, TL Club раз в месяц, где ребята делятся своими best practices, или «управленческие поединки», куда мы звали всех желающих и где ТЛ мог примерить на себя роль РП и наоборот, и т. д.). В конце концов знаний накопилось столько, что нам даже удалось сформировать их все в комплексный обучающий курс, который мы в итоге открыли для всех желающих и на котором уже отметили выпускные с несколькими потоками.

Масштабирование за счет outsource

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

Подрядчиками управляли тимлиды

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

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

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

Отдел по работе с подрядчиками

Так у нас появился «отдел ресурсного обеспечения» во главе с Юлей Грибовой. Отдел управлял всей этой базой и был мотивирован на своевременное предоставление требуемых команд с нужными компетенциями. Как водится, вначале это был Google Docs с реестром подрядчиков и их компетенций, но со временем это переросло в отдельную Outsource.CRM, в которой мы теперь ведем все карточки и контакты. Там же обрабатываются все запросы от наших сотрудников на предоставление подрядчиков.

Вот так выглядит наш Kanban по новым партнерам:

image-loader.svg

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

А так выглядят заявки на исполнителей:

image-loader.svg

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

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

База знаний

Из «папочек» в Confluence

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

Захотелось систематизировать информацию и иметь возможность полноценно с ней работать: добавлять комментарии, отсматривать версии, управлять доступом к тому или иному разделу и т. д.

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

Вот часть тогдашней иерархии хранения папочек для нашего сетевого диска:

image-loader.svg

А вот так стал выглядеть Dashboard проекта в wiki:

image-loader.svg

Очень много знаний

Не обошлось и без ложки дегтя: в процессе работы структура стала монструозной. Мы уже сами не понимали, где должен лежать тот или иной регламент, а новые сотрудники просто-напросто тонули в этом море информации.

Мы привлекли наших аналитиков, чтобы провести карточную сортировку и сделать структуру более user-friendly, подключили Google Analytics, и всё это помогло нам разложить всё по своим местам и понять, какие разделы следует вынести в закреп.

image-loader.svg

Со временем из одного Space (это такой раздел верхнего уровня в Confluence) мы пришли к разветвленной структуре, где каждый отдел имеет свое место со своими регламентами и полезной информацией, по каждому клиенту существует свой спейс, и всё это постоянно актуализируется и пополняется силами практически всех сотрудников компании.

На тему работы с базой знаний я бы мог написать не одну статью, поэтому закончу прямо сейчас.

Кризис таск-трекера

Нехватка функционала

Как я уже говорил в самом начале, у нас был достаточно своеобразный таск-трекер: возможность кастомизировать поля, управлять областью видимости, делать саб-таски и прочие прелести там напрочь отсутствовала. Кроме того, нельзя было задавать workflow для разных типов задач. Вот так выглядел интерфейс. Кто угадает название по внешнему виду? :)

image-loader.svg

Т. к. workflow у нас не было, мы костылили его вручную, описывая в wiki возможные шаги:

image-loader.svg

При этом никто не мешал перевести тикет из оценки сразу в работу, минуя стадию согласования. Почему 6b называется просто «Вёрстка», а 7b — «Выполнения плановые/Программирование», не помню, хоть убейте, но таков был путь.

I«ve got the power! Jira пришла в наш мир

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

Мы с Ваней Михеевым с остервенением занялись составлением «идеального» и «всё учитывающего» workflow, который призван был наконец-то заставить наши бизнес-процессы работать как единый отлаженный механизм. Когда у тебя в руках молоток, всё вокруг похоже на гвозди, и мы решили прибить гвоздями намертво все этапы, которые (как нам тогда казалось) обязательно должны были быть у каждой задачи.

Вот так «просто» стал выглядеть наш workflow:

image-loader.svg

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

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

Вот так workflow стал выглядеть по умолчанию:

image-loader.svg

Вот так он выглядит сейчас для одного из проектов:

image-loader.svg

А такой простой workflow у нас стал для тикетов типа Bug:

image-loader.svg

Сейчас мы опять рефлексируем про таск-трекер и проводим некоторые исследования, но это уже совсем другая история :)

За кадром

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

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

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

Вместе с тем за кадром осталось еще много всего интересного:  

  • про командную работу, которую мы с Ваней Антипиным выстроили для наших руководителей подцехов;

  • про целую структуру по инвестициям с Петром Федюшкиным;

  • про отдельный цех Education, который организовал Женя Лобанов и который возглавила Оля Парий;

  • про производственный PR & DevRel с Кристиной Ляпцевой;

  • про то, как Женя развивал и развивает AGIMA;

  • как Виталик Дощенко организовал Sales Team и во что она развилась;

  • про стратегические сессии форматом от бани до работы с приглашенным фасилитатором;

  • про то, как мы запускали Client Service и работу с качеством;

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

Я и мои друзья из AGIMA будем на AGIMA XV и с удовольствием можем вам рассказать там обо всем подробнее. Приходите!

© Habrahabr.ru