Управление командой

Мы хотим расти не только внутри в компании, но чтобы за её пределами это имело какой-то смысл. Наши руководители хотят простых инструментов и переговоров, чтобы как-то выдерживать диалоги на тему Хочу роста! или Хочу еще +X денег! А компания в то же самое время хочет развития компетенций и большей автономии сотрудников.

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

Почему мы вообще подумали, что нам карьерные уровни помогут?

В целом, у нас уже был развитый институт People Management: люди делали perf-review, one-on-one, встречались, разговаривали о развитии то есть почва для карьерных уровней уже была готова. Мотивация роста у каждого, конечно, была своя: кто-то хотел денег, кто-то признания, а кто-то растил собственную автономию. Путь у всех был разный, но главное люди уже хотели расти.

В то же самое время наши эйчары выяснили, что в компании более 75% профессионалов, т.е. каждый несомненный эксперт в своем деле, и в то же время среди них:

• Первые 40% были не автономны и нуждались в развитии то есть им постоянно была нужна помощь руководителя и/или коллег, чтобы делать их обычную работу.

• А другие 40% были автономны в собственной работе, но не отвечали за развитие других. Они сами были автономны, но вокруг трава не расти!

То есть с точки зрения компании только 20% сотрудников - гуд. Тогда мы изучили опыт топовых IT-компаний: ко такой тимлид, техлид и что происходит в Big 4 (Google,Amazon, Apple,Facebook) чтобы людей правильно направлять не только в нашем взаимодействии, но и в целом по жизни. По ходу дела мы также поняли, что у нас есть много людей, которые делают похожую работу то есть, генерализация тоже будет иметь смысл.

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

Зачем это руководителям?

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

Зачем это компании?

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

Зачем это сотрудникам?

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

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

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

Решение

Карьерные уровни можно было бы представить как-то так:

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

ЗП = компания + регион + (роль + карьерный уровень + ЗП-вилка) = грейд

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

• Смена роли;

• Смена карьерного уровня;

• Смена внутри уровня: изменение обязанностей, перф.

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

На внешние мы не можем повлиять:

• Рынок он такой, какой есть: одни люди становятся дороже, другие дешевле.

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

• И есть грустная правда: скиллы некоторых могут быть невостребованными прямо сейчас, и у них с зарплатой проблемы.

На что-то мы влиять можем:

• Очевидно, что на роли, карьерные уровни, на свой перф. Перф это raw performance человек просто больше работы делает. Или по другому: average как человек в среднем работает.

• На нашу стабильность вообще на нашу жизненную синусоиду, среднеквадратическое отклонение, насколько нас колбасит в работе.

Так что у нас очень сложно сделать вывод о зарплате людей из их карьерного уровня. Но карьерные уровни реально отражают интересы трех сторон сотрудников, руководителей и компании. Это тот самый трёхсторонний договор, который мы в итоге подписали.

Плоский граф требований

Мы начали с инженеров, потому что в них разбираемся. Мы написали много смартованных требований, типа: Коммуникация занимает не более, чем 20% времени инженера. И дальше для каждого уровня добавлялись новые:

Но в какой-то момент мы поняли, что зашли куда-то не туда. Что же пошло не так?

• Требования многократно наследовались. Кто писал код на каком-нибудь ООП, знает чтобы развернуть наследование очень далеко назад, нужен просто взрыв мозга, чтобы разобраться: Так, а кто сеньор? Вот этот? А он еще от миддла что-то наследует. жесть, в общем.

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

• Критерии были бинарными (смартовыми). Смарт это хорошо, но не в случае с людьми. Представляете, вдруг выясняется, что у кого-то какой-то процесс занимает 19% времени но зачем и как он это считал?! Но даже если посчитал вот он приходит к руководителю: У меня 19 А надо 21 и начинается bullshit.

Двумерная матрица

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

У нас получилось 7 уровней по горизонтали от 1 до 7. Это было лучше, но все же кое-что снова было не так:

• Семь уровней компетенций были неразличимы между собой. Например, уровень знаний на четверочку по семибалльной шкале что это значит? У нас никто так и не смог до такой степени глубоко прочувствовать все эти сферы, чтобы делить от 1 до 7.

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

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

Трехмерная матрица

Всего в этой табличке у нас было 42 строчки. Мы добавили веса, чтобы убрать дискретность всё стало гибко, подробно, но... стало просто ничего не понятно. Люди за пределами рабочей группы вообще перестали понимать, о чем мы разговариваем.

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

Двумерная матрица и линейка

Мы выделили 6 ключевых компетенций:

1. Знания,

2. Sharing,

3. Инновации,

4. Сложность задач,

5. Цель/Просто задачи,

6. Автономный менеджмент.

И описали для каждой те минимальные требования, которые удовлетворят карьерный уровень. Уровни же определили просто: 0 нет компетенции, 2 сформированная компетенция и т.д. Но снова не пошло, так как выяснилось, что описания уровней компетенций бессодержательны например, что такое conscious, я и сам с ходу забыл.

Тогда мы изучили крупные компании типа Google, Electronic Arts и т.д. и оттуда позаимствовали некоторые названия компетенций. Но все еще не хватало точности в определении, какого же уровня каждый сотрудник.

Area of Effect (AoE)

И тут мы подумали мы же игровая компания в конце концов! И ввели понятие Area of Effect (AoE), который измеряет постоянное и позитивное бизнес-влияние компетенции в текущей компании. Звучит длинно, а на мы соединили 6 компетенций и AoE от 1 до 5:

1 Сам человек, например, у него sharing прокачан только в себя;

2 Это что-то на команду. Сами решайте, что для вас команда например, это постоянная группа людей.

3 Несколько команд или несколько неопределенных групп людей;

4 Бизнес-unit. Например, мы считаем у себя в Wargaming, что это Platform. Но у кого-то это будет целая компания. Если кратко, то это достаточно крупная и независимая бизнес-организация со своими P&L и пр.

5 Очевидно, мир.

Как проверить, например, что такое Innovation 4? Это когда я могу выти и на весь бизнес-unit сказать: Иван Иванович инноватор масштаба нашей компании!, и если на галерке никто не заржал, то это, глядишь, и правда. Если заржал, то: Ну, ладно, инноватор вон тех Что?! Я понял. Двоечка.

Калибровка

Но когда мы начали маппить наших инженеров между разными компаниями, там такая дичь началась: тут все P4, а там все P5! Поэтому мы ввели калибровку для P4 и выше это помогло, хотя и не на уровне мира. Потому что никто не калибрует уровень P2 среди компаний карьерные уровни в них разные и с этим ничего не сделать. Но максимальный карьерный уровень может быть одинаковый, потому что он глобальный и инженеры из The Big Four задали нам верхний предел.

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

А польза-то какая?

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

В остальном мы все еще в процессе наблюдения и настройки. Мы все еще смотрим, насколько руководители работают с карьерными уровнями, насколько сотрудники понимают эти уровни и насколько они им помогли расти профессионально (не карьерно). Поэтому мы еще будем докручивать и досчитывать два пункта:

• Руководителям понятен подход и они им пользуются;

• Сотрудники знают, как могут расти довольные своим профессиональным ростом через год.

А пока я покажу вам на примерах, как работают карьерные уровни.

Примеры для инженерных компетенций

Knowledge

Что ожидается от инженера? Самое простое это knowledge. Это не какой-то knowledge в вакууме типа: Умею писать на Python, но ничего не знаю про базенки и vim никогда не открывал. Это знание какой-то специфики, которое в принципе трудоустраиваемое.

Ноль это отсутствие знания. А для единички, например, мы решили, что это около двух лет коммерческого опыта. Двойка это эксперт уровня команды в какой-то технологии, например, главный питонист в команде на 7 человек, главный эксперт в БД, в Кубе, в чем-то еще. А дальше с тройки по пятерку просто scale, например, тройка главный в нескольких командах, четверку по knowledge заработал бы главный эксперт в Python в бизнес-unit, а пятерку core-контрибьютор PostgreSQL.

Sharing

Sharing самая простая штука это насколько мы шерим.

Единичка это человек, который отвечает на вопросы. К нему подошли: Поможешь? Да. Он готов разговаривать. Если кто-то накрывается полотенцем и не отвечает, то это ноль. Начиная с двойки и в пятерку опять простой scale. Двойка шерит знания проактивно, и замечу, постоянно, с пользой для компании. То есть это не просто человек, который ходит и кричит: Перепишем все на OCaml! (Зачем, почему, мы вообще на 1С тут) должна быть польза, и она должны быть хоть как-то измерима, хотя бы каким-то экспертным мнением и в текущей компании, а не где-то в воображаемом мире. Это также может быть человек, который онбордит новичков в команде, причем по собственной инициативе. Пример пятерки это постоянный спикер на внешних интернациональных конференциях.

Innovation

Инновации это когда вы в компании предлагаете что-то полезное (польза определяется постфактум), и делаете это периодически.

Нолик, получается, ничего не улучшает. Единичка улучшает внутри себя, например, свои собственные методы работы. Двоечка улучшает внутри команды. Предложили что-то в команде, оно зашло о, несем в другие команды. Можно затащить в компанию то, что не является уникальным какой-то процесс, например, people performance process в компанию это будет уже четверочка, потому что с точки зрения компании это уникальная инновация. Пятерка это тот, кто изобрел React.js и вытащил его в мир.

Complexity

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

Отработать пятерку это создать компанию по сути дела, у меня это написано как Реализовать Platform. Четверка это тот, кто понял, как реализовать части этой компании, например, из чего состоит Platform: биллинг мы должны считать, большие фичи пилить, метод взаимодействия определить. Тот же TrackingID наш внутренний туллинг, считающий, как разные игры утилизируют наше железо это четверка отработал и внедрил его. И дальше по аналогии та же двоечка реализует какой-то спайк в Agile, например, маленький research на неделю, на две, на три.

Goals/tasks

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

Autonomy/management

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

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

Начиная с троечки начинается scale. От человека, который взял задачку и не только сам ее делает, но еще и за другими людьми присматривает. До того, кто присматривает за юнитом и драйвит инициативы в мировом масштабе.

Оценка карьерного уровня

Для каждого уровня мы сформировали краткие определения:

• P7 это неопытный специалист;

• P6 это вполне уже самостоятельный человек для типичных задач;

• P5 это полностью автономный эксперт, инженер. Он все уже может сам сделать и кого-то еще менторит в команде;

Начиная с четверки начинаются люди, которые развивают других людей:

• P4 это тот, кто развивает других P5 по сути дела, то есть тех самых автономных профессионалов;

• P3 развивает P4 и т.д.

Плюс тут еще важен scale. На уровне P2 мы ожидаем, что человек развивает нам примерно 100 P5. А это означает, что в компании на 10 человек быть P2 вообще нельзя но можно, если вы, например, развиваете локальное community питонистов, где 100 сеньоров. P1 это бог.

Теперь расскажу, как меняются ожидания в зависимости от уровня.

Минимальные требования

Плюс для каждого уровня мы определили минимальные требования:

Как видно, от P7 мы ждем только, что он какое-то complexity преодолевает и с какими-то задачками работает. Например, это студент, трудоустраиваемый на какую-то позицию в нашу компанию. Мы ожидаем, что он может погуглить и хоть что-то довести до конца. Он ничего пока не знает, поэтому и на вопросы не может ответить.

Если Р7 начинает учиться, то к следующему уровню (P6) у него уже должны подняться знания, он должен стать более автономным и начать отвечать на вопросы:

К уровню P5 наш студент уже вырос во всем и начал инновировать (прекрасное русское слово!). P4, как и P3, тоже растёт во всем параметрам:

А вот дальше интересно. P2 это, наверное, уже техдиректор, 100+ человек в компании. Это первый человек, который вышел на мир. Фактически мы ожидаем от него, что он начинает шарить инфу прямо на пятерочку в пределах всего мира. Эт тот человек, который компанию представляет уже на мировой арене и инновирует в масштабах всей компании. И P1, наконец, канонизированный техдиректор, бог он всё.

Что с этим делать на практике? Давайте посмотрим на примерах.

Пример оценок

• Про Лео можно сказать, что это в целом ровный чувак, который нормально шарит не в смысле в чем-то разбирается, а шарит информацию.

• Раф в чем-то прикольно разбирается, а в чем-то лучше своих коллег, и он массово учит людей. Это просто mass DDoS teacher людей!

• Майк очень автономный человек, который координирует какие-то задачки, он очень самостоятельный.

• А Дон не просто самостоятельный, он еще и сложные задачки решает самостоятельно вообще молодец!

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

Дальше появляется странная математика.

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

Пример плана развития

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

Кто такой Боб? Боб что-то классно знает, но, блин, никто не знает Боба! Он никому не рассказывает, чем он занимается. Он роняет задачки, которые в него вбрасывают. Вообще непонятно, кстати, как мы поняли, что он шарит? Кто-то сделал best guess, видимо. План развития Боба: Чувак, вылезай из угла.

У Пита вообще сложная жизнь. Он в чем-то лучше разбирается, у него неплохие идеи, но задачи ему лучше вообще не давать, их только вместе с PM стоит ему отправлять. У него много проблем.

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

Замечу, что карьерный уровень и вообще вся эта методология не для того, чтобы считать. Считать это первый шаг. Вы человека измерили, но для того, чтобы на основе среза в этот момент времени сказать, куда ему развиваться. Поэтому говорить: Я хочу себе +1 в карьерный уровень путь в никуда, тем более, что у нас, как вы помните, нет грейдов. Когда вы приходите к руководителю, он вас, конечно, сначала считает. Но потом вы с ним обсуждаете, как именно вам расти и следующий карьерный уровень приходит по мере того, как вы развиваетесь.

Вспомогательные механики

Еще мы используем некоторые техники, которые помогают нам понять, как развивать сотрудника в его карьерном уровне.

Карьерная лестница

Что такое карьерная лестница? Это что-то внутри software engineering либо внутри саппорта.

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

Карьерная карта

Я здесь в качестве примера привел P4 инженеров. А кто такой P4 Python разраб? Это же профессионал бэк-разработка и вообще software-инженерия. Но в целом это можно применить не только к инженерам.

Краевые случаи

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

A M-manager vs. a P-professional или лид внезапно

• Ключевая ценность: родитель или воспитатель в садике.

• Направление роста по соглашению с руководителем.

P (professional стрим) и M (manager) у нас отдельные карьерные пути, и это отдельный рост. Типовой запрос от внезапного лида обычно бывает: О, я кто P или M? То есть человек ждет, что я ему по методологии отвечу, но правильный ответ ты сам реши, кто ты.

Тут важен тот самый вопрос кем вы видите себя через 5 лет. Если вы собираетесь расти как профессионал, смотрите в P и растите там. Собираетесь расти как менеджер растите как M. Это зависит только от вас и вашей договорённости с руководителем.

Смена карьеры

• Роль определяется ключевой ценностью сотрудника.

Бывают кейсы, когда, например, QA-инженер P5 переходит в software engineering и у него падает карьерный уровень, он становится P7 либо P6. Это нормальная ситуация, и здесь нужно смотреть, какая у него ключевая ценность. Если он все еще трудоустроен, потому что в принципе в прошлом был хорошим QA, то возможно, какое-то время его стоит оценивать как QA. Если его взяли на software инженера и неважно, какой он QA ставьте ему P7 и растите как software инженера. То есть важно, вообще почему он у вас работает до сих пор.

Оценка новичков

• Делается на основе интервью и обсуждения ожиданий с руководителем.

Кто такие новички? Это люди с рынка, которых вы собеседуете. Тут важно с ними просто договариваться. Вы же не скажете им: Я беру тебя на P4 или на P5. Они такого не понимают. Но вы должны с ними договариваться о каких-то ожиданиях через какой-то срок. Это практически проект онбординга человека. Вы ожидаете от P4 вот это, и с этим человеком на входе договариваетесь: этого я ожидаю через полгода. Если через полгода не случилось, вы даунгрейдите человека это либо ошибка найма, либо самого человека. Но все равно нужно какой-то кредит доверия выдавать людям и договариваться.

Уровни в других компаниях

Прошлый уровень кандидата влияет только на его ожидания и зависит от:

• места компании на рынке,

• методологии которую использует компания,

• специфики технологий в компании.

Уровни в других компаниях другие. Есть компании, где ключевая сфера технологии (Google), а у кого-то e-commerce, и т.п. Очевидно, что нельзя, поменяв компанию, перейти на тот же уровень, потому что требования просто разные. Мы формулировки наших требований отправляем внешним рекрутерам в другие компании и спрашиваем: Эти люди у вас кто, судя по этим текстовым требованиям? Так мы делаем исследование рынка в текстовой форме.

То есть если к вам приходит человек с уровнем P2, то это влияет только на его ожидания и амбиции. Но вам толку от этого нет.

Понижения при внедрении карьерных уровней

• Это дар богов, освещающий путь.

Если вы будете внедрять карьерные уровни, и у всех станет минус 1 уровень, даунгрейд это прекрасно, это дар богов. Вы были P4-лидом, а теперь говорите: Я сеньор, и у меня P6 и это значит, что у вас будет четко обговоренный с руководителем план роста. У вас есть легко просматриваемые зоны роста, и это клево. Мы же не понижаем зарплату, мы этот инструмент используем именно для роста.

Недостижимые уровни или как попасть в Р1

• Вся жизнь между P6 и P5 это норма. Выше стресс и переработки.

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

Уровни и свобода личности

• Расти можно кем угодно. Но кто-то может быть не нужен компании.

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

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

Влияние на интервью

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

• Уровни могут быть рекламой компании.

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

Локальное внедрение

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

• Знать уровни во внешнем мире,

• Понимать, что важно компаниям в целом,

• Создать инструменты переговоров и оценки,

• Изучить ошибки в эволюции.

Для начала это можно сделать не на всю компанию, а на три команды, например. Или внедрить несколько частей поначалу, а затем добавить остальные. Будьте Ниндзей, который всех затащит!

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

А купив билет, вы можете получить в подарок мастер-класс Максима Дорофеева Как все успевать? На МК количество мест тоже ограничено мы должны соблюдать противоэпидемиологические меры и создавать дистанцию в залах. Поэтому гарантия участие в мастер-классе только предварительная запись.

До встречи на конференции TeamLead Conf 2021!

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

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

С другой стороны, совсем без инструментов, документации и дедлайнов справиться с проектом не получится. Это Дмитрий Ильенков из Project Management Club и автор канала @pmclub на конференции TeamLead Conf 2020 наглядно показал в своем выступлении. И там же познакомил нас с p3express с простым фреймворком для проектов любого размера. Этот минималистичный, но системный фреймворк для управления проектами предлагает 37 понятных шагов от идеи проекта до работы с выгодами по его завершению.

Большинство проектов, с которыми мы встречаемся практически каждый день, начинаются очень невинно с небольшой задачки, может быть, даже с просьбы:

Ты был на TeamLead Conf? Поделись, пожалуйста, с командой инсайтами!

Можешь помочь обновить сайт?

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

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

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

Этому есть несколько причин.

Проекты проходят мимо радаров

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

Много букв

Другая проблема давайте честно, управление проектами действительно ассоциируется со страшными вещами. Многие ставят знак равенства между управлением проектом и PMBOK. Редко кто PMBOK читал полностью от первой до последней страницы, и если это случилось, то скорее всего, это был PMP.

Я очень люблю PMBOK, и я PMP. Я был президентом Московского Chapter PMI. Но шестой PMBOK это 700 страниц, это реально много. Во-первых, ты их и сам не прочитаешь, а во-вторых, ты не заставишь, а тем более не убедишь прочитать их команду. А в-третьих, кто хочет для небольшого проекта использовать 700 страниц проектной методологии? Есть желающие? Обычно не находятся.

Нам уже было больно

Третья проблема: к вам в компанию приходили консультанты по управлению проектами? Я за последние полгода два раза столкнулся с абсолютно одинаковой историей в двух разных компаниях. К ним приходили консультанты, писали методологию и десятка полтора шаблонов.Люди пробовали заполнить эти 15 шаблонов, но даже 15 шаблонов это очень много. Им было больно, у них не получилось, им не понравилось. Они теперь ходят и рассказывают: проектное управление не работает! Хотят ли они попробовать еще раз? Спасибо, нет.

Возникает вопрос:

Что делать?

Что делать, чтобы управлять проектами как проектами, чтобы использовать лучшие практики и понятную канву, которую придумали до тебя, которая будет работать на тебя и которая будет работать еще дальше, когда ты ее адаптируешь?

Решением будет использовать более простые решения. Тот же самый PMI, правообладатель того самого PMBoK, у которого в шестой версии 700 страниц, в стратегии 2.0 прямо написал: Пришло время легковесных фреймворков. Седьмой PMBoK (я сейчас пишу к нему комментарии), который, надеюсь, выйдет в этом году, в части стандарта занимает только 37 страниц чувствуете разницу? Проще нужно, проще!

И я хочу рассказать как раз о простом, но при этом системной фреймворке, который придумали мои партнеры Надер Кей Рад (Nader K Rad) и Фрэнк Тёрли (Frank Turley). Надер как раз в числе авторов этого короткого классного PMBoK.

p3express

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

В чем его фишка?

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

В управлении проектами этого категорически не хватало до сих пор. Даже мой любимый PMBoK или очень красивый британский PRINCE2 никогда ни в одном месте не отвечают тебе на простой вопрос: что нужно делать завтра? Они пишут, что лучше делать так, есть принципы и процесс, следуй процессу, но завтра мне что сделать?

p3express это пошаговый алгоритм:

• Последовательно проходим 37 шагов, начиная от подготовки;

• Заходим в циклы, в которых работаем

• Выходим на закрытие проекта

• И дальше к пост-проектным активностям, когда извлекаем выгоды:

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

Контекст имеет значение, поэтому наполнение вы адаптируете сами. За счет этого p3express становится одновременно:

• Тиражируемым есть понятная система, ты берешь и переносишь ее;

• Адаптируемым за счет универсальности он подходит к проектам любого размера: от совсем небольших до более крупных.

Пройдем по шагам от начала до конца и посмотрим, 37 шагов это много или мало? Спойлер: немного.

Подготовка проекта

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

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

А01. Определить спонсора

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

Результаты исследования Пульс профессии (глобальное исследование в проектном менеджменте от PMI, обзор на русском) показывают, что компании, которые лучше управляют проектами и демонстрируют больше успешных проектов, чем в среднем, имеют большую поддержку со стороны спонсоров проекта. И около четверти проектов, которые прямо провалились, в числе причин провалов указывают низкую поддержку спонсора.

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

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

Третьей причиной (из-за которой лично мне больно) бывает то, что приходишь в компанию и спрашиваешь, есть ли у ваших проектов спонсор? Они отвечают: Да! У всех наших проектов есть спонсор. Это генеральный директор. У меня была своя история, когда я на эту ловушку попался. Я презентовал проект руководству компании, проект одобрили и даже дали подразделение в придачу. Я подумал все круто! А через какое-то время мне влетело еще несколько проектов, на меня повесили кучу рутины, а замруководителя, который меня курировал, сказал: Оставьте себе этот проект как хобби. Я посмотрел, как проект чахнет и ушел.

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

А02. Составить резюме

Здесь мы отвечаем на очень простые вопросы:

• Что мы хотим получить в результате проекта?

• Зачем это нам нужно?

• Сколько у нас есть на это времени и денег?

• Что может пойти не так? Другими словами какие риски могут возникнуть.

Ответы на эти вопросы мы упаковываем в простой одностраничный документ это и называется резюме проекта. И эти ответы дают нам понятную пользу: задают вектор проекта и его границы.

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

А03. Определить лидера проекта

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

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

А04. Развернуть рабочее пространство

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

А05. Определить команду

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

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

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

А06. Планирование проекта

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

Здесь же мы продолжаем работать с рисками. Не забывайте про выявление рисков (они вам обязательно встретятся) и про план, как мы будем реагировать на них.

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

А07. Определить внешних исполнителей

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

А08. Провести аудит подготовки

Еще одна особенность p3express это поддержка здоровья проекта. Мы любим что-то контролировать, или по крайней мере стараемся поддерживать проект в русле смотреть, чтобы он сильно не отклонялся от сроков и бюджета. Но почему эти отклонения происходят? У всего есть какая-то причина. Если мы действительно хотим поддерживать наш проект в русле, нам нужно искать проблему до того, как она становится уже пост-мортемом типа: да, мы не успеваем.

И первое в здоровом проекте это чек-лист Аудит подготовки. Перед тем, как принять окончательное решение запускаем проект! ответьте на несколько простых вопросов:

• У нас есть резюме проекта?

• Оно доступно команде?

• Мы развернули рабочее пространство?

• У членов команды есть доступ?

Шаблоны вопросов предлагает p3express, но вам нужно их адаптировать под себя, чтобы они принесли реальную пользу.

А09. Да/нет

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

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

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

А10. Провести kick-off

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

А11. Фокусированная коммуникация

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

Не надо партизанить, коммуницируйте о проекте с теми, к кому он может относиться.

Циклы

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

Планирование цикла

А12. Обновить планы

Мы провели небольшой опрос в Telegram: из 180 тимлидов около 30% назвали главным своим челленджем в ушедшем году постоянную смену приоритетов.

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

А13. Определить внешних исполнителей

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

А14. Да/нет

Каждый месяц отвечайте на вопрос: нужно ли продолжать проект? Мы иногда забываем, когда следует закончить проект. Один ответ очевиден мы все сделали, передаем результаты своей работы. Но бывают другие причины для остановки и закрытия проекта. Например, он утратил свою актуальность, изменилась ситуация в компании или изменилась ситуация на рынке. Зачем продолжать тратить ресурсы, если их можно переключить на что-то более полезное?

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

Итак, если решение положительное, то переходим к следующим шагам.

А15. Провести kick-off цикла

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

А16. Фокусированная коммуникация

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

Еженедельные действия

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

А17. Оценить прогресс

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

Что нужно проверить?

1. Метка-статус vs комментарии. Проверьте, соответствует ли метка-статус комментариям к продукту. Противоречий быть не должно. Для наглядности и простоты вы можете, например, использовать цветовые метки: зелёная продукт готов, жёлтая продукт в работе, красная продукт не готов/проблема с продуктом.

2. Результаты vs контрольные точки. У вас могут быть контрольные точки как по всему проекту, так и по элементам конфигурации проекта. Проверьте, все ли точки пройдены вовремя? Вы не пропустите важный дедлайн?

3. Результаты vs бюджет. Сравните план по использованию бюджета с фактическими данными. Если перерасход, то по какой причине? Сделали больше запланированного или причина серьёзнее? Если бюджет не освоен откуда взялась экономия?

4. Сопоставьте прогресс с другими проектами. Вы работаете не в вакууме: какие-то отставания критичны, а какие-то нет, если в связанных проектах всё стоит.

5. Слушайте, что говорят. Слухи расходятся быстро, и в них может быть правда. В рабочем пространстве всё идеально, а коллеги сочувственно смотрят в вашу сторону? Что-то идёт не так.

А18. Работать с отклонениями

Работаем с найденными отклонениями (если требуется наше активное участие):

1. Убедитесь, что вы собрали полную и достоверную информацию;

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

3. Выберите наиболее острые проблемы;

4. Соберите дополнительную информацию;

5. Решайте проблемы на своем уровне или выносите их на уровень спонсора;

6. Помните, ваша задача решить проблему, а не найти крайних.

А19. Еженедельная встреча

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

А20. Еженедельный аудит

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

А21. Фокусированная коммуникация

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

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

Сделано? Сделано. ОК.

Не сделано? Смотрим почему. Но ни о чем не спорим, ничего глубоко не обсуждаем, просто тэгаем того человека, который может решить эту проблему и внести вклад в обсуждение.

Такие звонки у нас длились полчаса максимум, и 15 минут из этого времени уходили на Как дела? Мы так рады с вами работать! все эти американские любезности. То есть мы успевали всё обсудить за 15 минут. После созвона лидер проекта направлял коммуникацию команде, что происходит в части работы с этим подрядчиком.

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

Почему мы плохо пользуемся такими инструментами?

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

2. Второй вариант люди не очень понимают, зачем это надо. Тоже можно объяснить.

3. Третья ситуация смешнее и страшнее. Я ее наблюдал сам.

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

Но вице-президент на эту встречу не пришел это был первый звоночек. Второй звоночек был, когда его помощник нам сам создал доски и направил туда приглашения. Через пару недель вице-президент спрашивает: А что вы не ведете ваши доски?, но сам при этом так и не зарегистрировался в Trello.

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

Ежедневные действия

Это даже не шаги, а рекомендации к ежедневным действиям. Каждый день мы сталкиваемся с какими-то новыми задачами, проблемами и рисками. RICs это риски, проблемы, запросы на изменения. Тот же наш опрос тимлидов показал, что одна из проблем это постоянно прилетающие новые задачи. И это неизбежно.

Что можно делать?

А22. Зафиксировать RICs

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

А23. Реагировать на RICs

Мы на них обязательно реагируем. Если не можем справиться с проблемой сами, не стесняемся ее эскалировать, потому что лучше эскалировать проблему, а не провал и/или катастрофу.

А24. Принять готовые продукты

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

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

А почему возникает мультизадачность? Это происходит не только потому, что нам постоянно прилетают новые задачи, но и потому что мы не закрываем старые.

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

Принимайте результаты работы как можно чаще!

Закрытие цикла

Каждый цикл мы открываем и закрываем.

Закрытие цикла состоит из трех шагов:

А25. Оценить удовлетворённость заказчика и команды

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

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

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

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

А26. Запланировать улучшения

Прогресс сам по себе не придет. Нужно понять, где можно работать лучше, что для этого нужно сделать.

А27. Фокусированная коммуникация

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

Закрытие проекта

А28. Передать продукт

Вы уверены, что передавая продукт, вы его передаете правильным людям? Со мной случилась (к счастью, это было давно) очень забавная история. Компания, где я работал, решила внедрить довольно дорогую систему бизнес-аналитики. Купили 5 лицензий.

Результат:

• Сколько из них пошли пользователям? Всего одна, две отдали айтишникам, две топам.

• Сколько человек обучили пользоваться этой системой? Одного из айтишников (самого хитрого). Он стал носителем сверх-знаний и не потерялся через полгода стал начальником отдела по работе с этой системой.

Система, кстати, все равно не взлетела, потому что это криво: я пользователь, а у меня нет ни лицензии, ни навыков работы.

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

А29. Передать проект

Проект нужно передавать так же, как и продукт. Проект может быть закончен для лидера проекта и для команды, если это временная команда. Но компания просто выбросила деньги, чтобы вы собрались, что-то сделали и ушли? Тогда проще было заказать. А что с извлеченными уроками? Что с поддержкой продукта, который вы создали? Что с тем же самым заказчиком кто будет продолжать контакт?

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

И в идеале именно этот человек проходит следующие шаги.

А30. Оценить удовлетворённость заказчика и команды

Последний раз оценивается удовлетворенность заказчика и команды.

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

А31. Провести аудит проекта

В целом оценивается эффективность управления проектом.

А32. Извлечь уроки

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

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

А33. Отметить окончание проекта

Можно сколько угодно говорить про выгорание, но если человек приходил на работу, делал-делал проект, не спал ночами и, завершив проект, пошел домой, поспал, вернулся и у него новый проект это похоже на день сурка, причем паршивый день сурка. Не надо этого допускать. Умейте радоваться жизни Work Hard & Play Hard, отмечайте с командой все достижения, а окончание проектов тем более.

А34. Фокусированная коммуникация

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

После проекта

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

А35. Оценить полученные выгоды

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

Мы об этом часто забываем. В презентациях часто красиво написано: Внедрение CRM сократит ваши расходы на отдел продаж на 100%! Мы сократим расходы на ФОТ!. Подождите, сокращение расходов на ФОТ это значит, кого-то уволили. Это называется disbenefits то, что для кого-то хорошо, для кого-то плохо.

А36. Спланировать дополнительные действия

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

А37. Фокусированная коммуникация

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

• По мотивации;

• По улучшению проекта. Люди должны понимать, что от них ожидают;

• По борьбе с бесполезными проектами.

Есть статистика от The Standish Group, сколько процентов фич никогда не используется. Такой статистики по проектам я не нашел, но к нам часто приходят с бесполезными проектами, которые мы тем не менее делаем. Но без коммуникации и измерений мы не можем потом сказать: Нам кажется, что ты нам только бесполезные проекты приносишь.

Измеряйте выгоды, коммуницируйте!

Выводы

Мы прошли все 37 шагов это оказалось не так много. И они все уместились на доске в нескольких колонках:

Я действительно люблю p3express. Мне нравится, что им просто пользоваться, что я могу пользоваться им не один, а управлять проектом вместе с командой, потому что объяснить, как это делать в p3express достаточно просто.

Пробуйте p3express на небольших проектах в вашей компании, пробуйте на своих pet-project, пробуйте масштабировать, раскатывать и помогать другим.

Simplicity is the ultimate sophistication!

Московская конференция TeamLead в этом году пройдет 29 и 30 апреля в Radisson Slavyanskaya. На конференции будет огромное количество информации, общения, обсуждений для тимлидов команд любых размеров и направлений. Не только для IT-сферы, не только для больших корпорация или маленьких старпапов. О том, как строить (и перестраивать) культуру в компании, как развиваться самому и помогать в этом команде, как решать конфликты для всех с профитом, про бизнес-процессы, коммуникацию, карьеру и многое другое вы получите максимальную концентрацию тимлидского опыта на чел/час и кв.м.

Расписание конференции уже готово.Билеты уже в продаже. Можно участвовать как онлайн, так и по старинке, общаясь вживую. Присоединяйтесь!

Но если вы хотите еще и выступить, на питерскую конференцию Saint TeamLead Conf 2021 еще открыт прием докладов. Мы помогаем спикерам во всех вопросах выступления, в том числе учим выступать и как подготовить презентацию. А в Программном комитете ваши заявки просматривают и отбирают опытные спикеры, неоднократно выступавшие на разные темы и эксперты в своих направлениях. Выходите на свет рампы вместе с нами!

В 2021 году половина российских компаний планирует нанимать временный персонал для привлечения к проектной деятельности. Это показал опрос Hays, в ходе которого высказались почти 5 тысяч респондентов. 15% из них планирует за счет аутстаффинга оптимизировать свои расходы. 7% опрошенных испытывают сложности с поиском подходящих сотрудников в штат.

Компании Holyweb, которая специализируется на аутстаффинге ИТ-персонала, стало интересно, что стоит за этими цифрами. Они решили задать вопросы непосредственно тому, кто принимает такие решения руководителю разработки на стороне клиента.

Глеб Корсунов, CBDO Holyweb, обсудил с Михаилом Кебичем, руководителем разработки публичного облака Mail.ru Cloud Solutions, какие существуют опасения относительно аутстафф-подрядчиков, как безболезненно подключить внешних специалистов к инхаус-команде и как влиять на их мотивацию.

Приятного чтения!

Стоит ли бояться, что подрядчик выйдет из проекта или заберет половину команды?

Функция аутстаффинга дополнять, усиливать или заменять команду заказчика. Это рабочий инструмент, у которого есть свои плюсы и минусы. Мы в Mail.ru Cloud Solutions им пользуемся и нам он помогает.

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

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

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

С помощью аутстаффинга мы решаем задачи управления ресурсами быстро привлечь под задачу дополнительные руки и так же быстро сократить этот ресурс, если он не нужен здесь и сейчас. Если кто-то из аутстафферов уйдет, на наш бизнес это никак не повлияет. У нас своя разработка: все, кто отвечает за предоставление сервиса в режиме 24/7, работают во внутренних командах Mail.ru Cloud Solutions. На аутстафф мы стараемся отдавать полностью отчуждаемые задачи, чтобы они находились в зоне ответственности одной команды разработки от и до. Это могут быть сложные и объемные проекты на нескольких месяцев. Впрочем, мы всегда стремимся уменьшать циклы разработки стандартный спринт для инхаус-команды составляет две недели, и аутстафф двигается в том же ритме.

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

Как отношение инхаус команды к аутстафферам влияет на качество сотрудничества?

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

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

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

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

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

Как доверять, но проверять?

Универсальный совет выделите сотрудника, который следит за загрузкой специалистов и администрирует всю работу аутстафф-команды.

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

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

Эта позиция в той же степени распространяется и на внутренних сотрудников Mail.ru Cloud Solutions.

Аутстафф-сотрудники не такие мотивированные, как штатные? Так ли это и как можно на это влиять?

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

При правильной организации процессов и хорошем онбординге вовлеченность и мотивация аутстфферов сопоставима с мотивацией штатного специалиста.

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

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

Когда можно делать первые выводы об эффективности аутстафферов? Первый месяц работы самый важный?

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

Если аутстаффер работает внутри команды, то мы в Mail.ru Cloud Solutions оцениваем его точно так же, как и штатных сотрудников. Онбординг новых специалистов занимает столько же времени, они полностью интегрируются в команду и работают по той же системе и с теми же KPI, что и инхаус-разработчики. КПД каждого отдельного разработчика измеряется в зависимости от сложности сервисов и задач, с которыми работает его команда. Быть эффективным и попадать в сроки команды невозможно без качественной коммуникации.

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

При оценке внешней команды мы смотрим на ее результативность. Качество коммуникации можно оценить уже в начале работы. Через 2-3 недели становится понятно, насколько аутстафферы проактивны, самостоятельно инициируют обратную связь или нет, сразу ли сообщают о возникшей проблеме, предлагая собственные пути решения.

Как найти баланс при подборе разработчиков не перегнуть палку и не проглядеть подходящих кандидатов?

Мы проводим полноценное техническое интервью такое же, как для сотрудников Mail.ru Cloud Solutions, которых берем в штат. Обязательно уделяем внимание софт-скилам разработчика и его кругозору. Кроме того, устраиваем собеседование с руководителем команды и продуктовым менеджером.

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

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

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

Остались вопросы? Пишите в комментарии или Глебу в Facebook ответим всем.

Если вы хотите присоединиться к команде Mail.ru Cloud Solutions: прямо сейчас открыты вакансии Python/Go-разработчика в команду PaaS и Go-разработчиков в команды объектного хранилища и IAM.

Полный и актуальный список вакансий MCS.

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

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

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

Но вот что примечательно: Jira преподносит себя как "рабочий инструмент номер один для гибких команд". Гибких? Хм-мм... Если для управления Jira нужен особый человек или даже целая аутсорсинговая компания, о какой гибкости можно говорить?

Давайте разберёмся, что вообще означает термин "гибкий" (Agile) и почему про него все сегодня говорят?

Последовательная разработка

Сегодня только и разговоров, что про методику Agile, как раньше про методику Waterfall. Впервые каскадная методика Waterfall была описана Уинстоном Ройсом в статье, опубликованной в 1970 году. Хотя термин Waterfall (каскад) не был употреблён в статье ни разу, описание метода напомнило многим каскадную схему:

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

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

Единственной проблемой при применении такого подхода к разработке программного обеспечения является его малая эффективность как в прошлом, так и сейчас эта методика постоянно даёт сбои.

Встреча в Сноубэрд

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

Это хорошо понимала группа разработчиков, собравшихся на горнолыжном курорте Сноубэрд в США в 2001 году. Они согласились с тем, что при изменении требований процесс разработки пойдет насмарку, а, так как препятствовать изменению требований невозможно, любая используемая методика управления процессом изначально обречена на провал. Так как же быть? Выход подсказал Александр Великий, разрубивший некогда Гордиев узел.

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

Изменение требований на поздних этапах является конкурентным преимуществом

-Мэри Поппендик

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

Основные положения манифеста:

• Люди и взаимодействие важнее процессов и инструментов.

• Работающий продукт важнее исчерпывающей документации.

• Сотрудничество с заказчиком важнее согласования условий контракта.

• Готовность к изменениям важнее следования первоначальному плану.

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

Что произошло?

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

Корень зла, согласно прагматическому замечанию Дэйва Томаса, кроется в том, что слово agile прилагательное, превратилось в Agile (собственное) существительное. Существительные продаются лучше, чем прилагательные, и даже возник "Промышленный комплекс Agile", приторговывающий маркой "Agile".

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

Если идея гибкости возникла в результате признания того факта, что мы не можем предвидеть, как именно могут измениться требования, то единого решения (процесса), которое подошло бы для всех возможных сред, не может быть просто по определению. "Agile-эксперты" навязывают нам определённый процесс, и такое состояние Мартин Фаулер называет неприкрытой пародией на "гибкость".

Как же так, вообще без процесса?

Но нужен же какой-то процесс, разве нет? Нужен, но какой? Да очень простой использовать всё, что работает! Но как узнать, будет ли он работать? Тут следует применить эвристический подход.

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

Инструменты

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

Инструмент, подходящий под это описание и имеющийся в каждом офисе, уже имеется!

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

Что не так с Jira?

Если не вдаваться в детали, Jira не нравится мне тем, что она навязывает пользователю определённый процесс. Но этим дело не ограничивается. Я даже был свидетелем того, как команды разработчиков были вынуждены подстраивать свои процессы под Jira, что является грубым нарушением принципа "Люди и взаимодействие важнее процессов и инструментов".

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

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

Между прочим, Atlassian (компания-разработчик Jira) постоянно ищет себе инженеров по различным направлениям, в числе прочих нужны Fullstack-разработчики и Java-разработчики. Если одна из ваших целей релоцироваться в компанию с мировым именем, то приходите учиться, прокачаем ваши скилы и поможем выгодно представить их в резюме.

Узнайте, как прокачаться в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering

Привет, Хабр! Меня зовут Александр. 17 лет в КРОК. В основном занимаюсь разработкой и внедрением заказного ПО, хранилищ данных, решений Big Data для бизнеса и госсектора. Начинал консультантом по внедрению и последние 11 лет работаю менеджером крупных комплексных проектов. А еще я немного пожарный, потому что регулярно помогаю коллегам тушить проектный огонь.

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

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

Про коллаборацию заказчика и соисполнителей

В больших проектах всегда интересно, и часто они преподносят разные челленджи, но тем они интереснее. Мой первый крупный проект (это было внедрение ЕМИАС в поликлиниках Москвы) случился аккурат под новый 2011-12 год, когда у клиента началось активное внедрение новых сервисов в здравоохранении для граждан, сопровождаемое не менее активной информационной кампанией. И мы тоже несли ответственность за развиваемый клиентом бренд ЕМИАС. Огонь возник в условиях готовящейся инфраструктуры и интенсивно развивающегося ПО. Новая функциональность выходила чуть ли не каждую неделю, партнеры готовили СКС, мы доставляли АРМы врачам, устанавливали, подключали, обучали регистраторов заводить расписание, врачей работать с приемом пациентов, запускали и настраивали бизнес-процессы, связанные с внедрением новых сервисов. И все это на фоне ожиданий со стороны правительства Москвы и лозунгов в прессе, что вот новая функциональность, вот новые поликлиники подключили. Таким образом перед нами ставились весьма амбициозные цели и сверх амбициозные сроки.

Как справились с огнем? В этом проекте, который мы развиваем по сей день, очень помогают плотная коллаборация с командой на стороне заказчика и задушенная на корню бюрократия на стороне соисполнителей, обеспечивающих сервисы для функционирования ЕМИАС. Я вспомнил про этот сложный проект, чтобы отметить одну из основных лучших практик в масштабных проектах обязательное наличие квалифицированной команды, обладающей полномочиями оперативного принятия управленческих решений на стороне заказчика. Без этого подобные проекты обречены. Проблемы вроде не работает сетевой порт решались одним звонком коллегам от провайдера, а не отписками заведите обращение, подождите, пока оно пройдет многоступенчатую эскалацию и вообще у нас заказчик не КРОК вовсе обращайтесь через них. Такая слаженная, ориентированная на общий результат целой группы компаний работа, вот лучшая практика и один из важных для меня уроков после этого проекта.

Про коллаборацию заказчика и соисполнителей еще раз

Годы работы в проектах ЕМИАС преподносили нам очень разные вызовы в 2013 у нас была команда внедрения с 700+ консультантами во всех амбулаторно-поликлинических учреждениях Москвы. В 2018 нам надо было найти 100+ консультантов для внедрения лабораторного сервиса ЕМИАС это два месяца собеседований нон-стоп. Но оно того стоило!

Как справились с огнем? Тут, опять же, заказчик помогал в согласовании плана внедрения на стороне объектов внедрения с постепенным наращиванием оборотов и административным ресурсом с оповещением поликлиник, лабораторий. Это еще раз подтверждает тезис необходимости совместной мощной команды не только со стороны исполнителя, но и заказчика. В сложных проектах верно выстроенный процесс взаимодействия и коммуникаций (читай синергия команд обеих сторон процесса) путь к успеху. И вторая мораль этой истории не бояться огня. Глаза боятся (осознав, сколько нужно консультантов и в какой срок, задача казалась нерешаемой в принципе), а руки взяли и сделали! Хоть и собеседования проводили всем миром.

Про ток, или Как снять напряженность клиента

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

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

Про важность работы напрямую с бизнес-заказчиком и решение именно его задачи

Несколько похожая, но вместе с тем иная ситуация была у меня и в другом проекте, где мы для одного из банков делали Big Data систему для построения профиля клиента и оценки рисков при выдаче кредита. В момент подключения меня в проект была не первая фаза, а я не первым РП на стороне исполнителя. Ситуация была схожа с прошлым кейсом непрозрачный процесс разработки для заказчика усугублялась отсутствием четкого ТЗ, ибо такого рода систем в банке, да и на рынке, в то время по сути еще никто не делал. Были первые ласточки в банке Т и банке А, однако готовых решений (да еще на open source) не было. По сути строили с нуля, склеивая кусочный опыт в комплексное решение, попутно синхронизируясь с заказчиком. И еще требования бизнес-заказчиков ловко и резко менялись по ходу представления.

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

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

Про не всемогущий agile

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

А от исполнителя нужно только локальное управление внутри задач и команды, приоритеты и контроль, состав спринтов. Работали по T&M, еженедельно отгружая таймшиты. При этом нам полностью доверили экспертизу и проектирование системы и ее архитектуры, но на входе дали лишь основную суть бизнес-задачи. Детальное исследование и постановка была тоже на нас. Главная проблема была в том, что кроме РП со стороны заказчика в его команде первые два месяца по сути никого не было. И осознал он (мы заметно раньше) эту проблему только через два месяца работы. То есть когда мы, во-первых, не дошли до ожидаемого им результата (напомню, управление на стороне заказчика) и, во-вторых, ему показалось, что выставленный счет слишком высок, несмотря на регулярные таймшиты, которые принимались и фиксированные ставки договор-то был по T&M. Пахло кризисом жанра. Ситуацию усугубляло еще и то, что со стороны заказчика, как и в прошлом кейсе, системы-источники для разрабатываемой системы были не готовы с нами интегрироваться, а заказчик отказывался принимать результаты работ без демо работоспособного решения.

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

Про опытных пожарных

Так исторически сложилось, что я начал помогать решать проблемные ситуации и в проектах коллег. И за последние несколько лет не было и года, чтобы я не помогал тушить по крайней мере один пожар, ну, или снижать градус жары. Тут бывали разные ситуации. Например, в одном проекте крупной торговой сети я не занимая место основного РП, помог усилить команду управления. В мои задачи входило: перезагрузить отношения с командой заказчика, пересогласовать план работ и успешно довести проект до завершения. Еще в одном проекте была как раз смена менеджера, в котором я поработал над реструктуризацией графика в угоду общей цели проекта. Пожара не было в итоге. Ну и вообще иногда полезен взгляд со стороны сам пользуюсь этой опцией в своих проектах. У нас в командах это практикуется.

Мало огня?

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

Этот кейс был особенно сложен еще и тем, что по ходу проекта (это более 1,5 лет) многие задачи делались от потребности заказчика в моменте, без оглядки на ТЗ. К концу проекта оказалось, что сделана гигантская работа, но не по ТЗ. Хотя многое реально потеряло актуальность за время проекта. А подписались-то мы под ТЗ. И особенности конкретного заказчика были таковы, что невыполненные требования ТЗ к принимаемой системе это путь под откос.

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

Противопожарные меры

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

Со стороны исполнителя важные и проблемные места, которые могут привести к пожару:

1. Отсутствие полной команды управления исполнителя. Для КРОК это два менеджера РП и технический менеджер ТМ, а для комплексных проектов с несколькими командами РП и несколько ТМ;

2. Проблемы коммуникаций не пускают к функциональным заказчикам;

3. Проблемы коммуникаций между смежными командами внутри исполнителя (тоже бывает не так уж редко), и, конечно, с командами заказчика;

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

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

Со стороны клиента:

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

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

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

Про самое важное в проекте для исполнителя про команду

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

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

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

Другим классным инструментом, которым в КРОК по мере возможности пользуюсь тимбилдинги. И это вовсе необязательно замороченное мероприятие типа командной сдачи норм ГТО (хотя и такое было, и это было огонь!). Тут можно и просто собрать команду в неформальной обстановке, пообщаться, поиграть в дженгу и киккер и просто снять таким образом напряжение зума, тимса, вебекса и бесконечных созвонов-созвонов-созвонов Это работает! Я проверил!

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

Вместо заключения

У меня не было цели описать чудесную пилюлю и раскрыть секретное заклинание о том, как починить любой проект. Универсального лекарства нет, проекты уникальны. Прямо тиражных решений в КРОК очень немного в основном мы строим сложные, часто уникальные системы для клиентов, глубоко кастомизируя их. За это нас ценят мы умеем склеить то, что раньше никто не клеил и построить даже кажущиеся безумными решения. Одно в моем опыте работы остается неизменным это отношения с людьми. РП зарабатывает авторитет не тогда, когда говорит и делает то, что хочет заказчик, а тогда, когда не пасует перед сложностями в согласовании реструктуризации плана проекта и трезво оценивает ситуацию, готов оперативно реагировать на вызовы в проекте, подключать нужные ресурсы. Поверьте, заказчик будет вас уважать, даже если вы нарисуете новый план со сдвигом сроков, но! все эти новые сроки выдержите. РП сказал = РП сделал вот главная сила и рабочее решение большинства сложных ситуаций.

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

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

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

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

Начнем со знакомством с философией трех путей:

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

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

• Третий Путь пропагандирует культуру постоянного эксперимента. Движение дорогой проб и ошибок позволяет организации расти и развиваться.

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

О них дальше и поговорим.

Визуализируйте всю работу

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

• бизнес проекты - тип работы, которая создает ценность для конечного пользователя и/или конкурентное преимущество организации;

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

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

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

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

Выявляйте ограничения

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

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

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

Устраняйте ограничения

Горы незавершенной работы указывают не только о наличии ограничений, но и увеличивают время нахождения работы в процессе. Одним из способов решения данной задачи является сократить количество новых работ, в которых задействовано ограничение. Вторым способом является расширение ограничения. Каждый производственный участок можно охарактеризовать 4 вещами: машиной, человеком, методом работы и измерениями. Соберите больше информации об ограничении, и попробуйте наиболее доступный вам вариант для его расширения. Не пытайтесь улучшать систему вне ограничения, это дает иллюзию улучшений, но не решает реальную проблему. В своей практике, я первым делом начинаю решать задачу первым методом. Если возникает ограничение в производстве, то намного быстрее сфокусироваться на том, что перед ним - генерации и проверке идей. Только убедившись, что в работу идет самое ценное я перехожу к методу расширения ограничения. Второй метод не только дороже, но и дольше. Найм и обучение человека, который потенциально поможет расширить ограничение, займет от нескольких месяцев до полугода, а количество работ в процессе вы можете ограничить за недели, иногда и быстрее.

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

Устраняйте движение против потока

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

Наладьте обратную связь

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

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

Экспериментируйте

Развитие технологий и глобализация открыла новые возможности для бизнеса. Сегодня маленький стартап из Израиля или Беларуси, может конкурировать с гигантом из США или Европы за аудиторию. Пользователь становится более избирательным, а конкуренты не дремлют. Если вы будете довольствоваться тем, что есть, то очень быстро вас догонят и перегонят. Эксперименты - основа основ для развития. Как сказал Эдисон: "Каждая неудавшаяся попытка это еще один шаг вперед". Чем больше компания экспериментирует тем выше ее шансы найти нужный подход к аудитории и монетизировать его. Это и есть ключ к третьему пути.

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

Когда-то форум локального интернет-провайдера был площадкой для знакомств, источником контента и местом, где вы встречались с товарищами по гильдии в World of Warcraft. Но могут ли механики форумного общения быть полезными в эпоху чатов?

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

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

Как люди читают форумы

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

Идея как-то структурировать общение оказалась настолько удачной, что форумы до сих пор живее всех живых хотя появились они ещё в 80-е. Правда, форумное общение не похоже на Facebook или переписки в чатах.

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

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

Высокий порог входа

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

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

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

Но принципы общения на форуме могут помочь, когда участников в чате становится слишком много.

Почему групповые чаты не работают

Попробуйте собрать 10 друзей в одной переписке. Возникнут очевидные неудобства:

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

• Не хватает времени, чтобы следить за обсуждением. Некоторые участники перестают понимать, что происходит.

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

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

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

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

Чат vs форум

Допустим, есть 10 друзей, которых вы хотите позвать в поход. Для этой цели вы создаёте новый чат в телеграме.

Нужно обсудить четыре вопроса: маршрут, время отъезда, список припасов, а также сколько скидываться на покупки и бензин.

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

Если задавать вопросы по одному: анализировать ответы станет проще, но общение затянется. Этапы идут в чёткой последовательности нельзя зайти и разом ответить на всё, что нужно.

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

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

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

Форум добавляет ещё один структурный слой. Чаты это треды, а над ними мы делаем надстройку в виде разделов. Благодаря этому следить за обсуждением становится легче.

Как мы сделали форум внутри таск-трекера

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

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

• Интерфейс приложения должен быть ориентирован на чат. В YouGile так и есть, общение по задачам основная идея нашего сервиса.

• Карточка должна показывать, что в треде есть новое сообщение. Иначе будет неудобно их проверять.

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

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

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

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

За неделю получили более 300 комментариев, идей для улучшений хватит на много спринтов.

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

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

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

Пообщаться на форуме

Кстати, вы можете создать свою доску-форум это бесплатно, без ограничений. Если захотите организовать работу команды вYouGile, то до 10 человек все функции тоже доступны бесплатно (это навсегда).

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

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

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

Первый этап: Обида

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

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

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

Второй этап: Отсрочка

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

У сотрудника обостряется чувствительность. С одной стороны, он начинает обращать внимание на те факторы, которые существовали и раньше, но были незаметными. Они мелкие и малозначащие, но сейчас, в комплексе с основным фактором, они приобрели новый вид - более неприятный. С другой стороны, сотрудник теперь сразу замечает новые факторы, как только они появляются.

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

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

И большинство сотрудников берут отсрочку. Мало кто готов взять и сразу уволиться. Кто-то ждет понедельника, кто-то решает уйти после отпуска, а кто-то планирует пересидеть более длительный срок. Зачем? Несмотря на то, как сильно обидели сотрудника, у него могут быть обязательства, которые не позволяют ему принимать горячие и необдуманные решения (ипотека, семья, обучение, ...).

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

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

Почему? Ответ простой. Какой смысл вкладываться в компанию, в которой ты работаешь временно?

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

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

P.S. Мой пример - не догма. Есть разные сотрудники и разные ситуации.

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

Второй пример, если сотрудник в хороших отношениях с руководителем и не хочет его подвести. Тогда он будет работать ради него на 100%.

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

И прочее...

Третий этап: Увольнение

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

В этот период ему уже крайне все равно. Он не боится прогулять, он не боится что-то не сделать, он не боится в рабочее время проводить собеседования (тем более сейчас этому способствует удаленная работа). Он может спокойно, даже не скрывая, посвятить свое время поиску. Он не боится последствий. Ведь, что может сделать с ним его босс? Уволить? Так он и так увольняется :)

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

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

Что видит руководитель?

Когда сотрудник принял решение об увольнении и начал работать не так, как нужно - его результаты стали хуже. Он стал менее лояльно коммуницировать, у него изменился внешний вид, он стал более серьезным. Так продолжается день, неделю, месяц. Руководитель, наблюдая за таким изменением, и не понимая истинной его причины, начинает отзеркаливать такое отношение (не специально, это происходит на автомате). Он удлиняет дистанцию, начинает более жестко коммуницировать, усиливает контроль, меньше вовлекает. Ведь как по другому, когда сотрудник себя так ведет? Почему я должен с ним сюсюкаться? - думает он. И, такая реакция вполне естественна. Согласитесь, очень сложно быть добрым и мягким с тем, кто не отвечает взаимностью.

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

Весь этот период (последние дни жизни) руководитель видит только то, что работа и отношение сотрудника ухудшились, и продолжают ухудшаться. И, когда сотрудник наконец-то увольняется, руководитель с облегчением выдыхает: "Ох и отлично. Испортился и стал плохо работать. Начал дерзить. А ведь мы же ничего плохого ему не сделали".

Как правильно: испортилСЯ или испортиЛИ?

Мы закончили кейс словами руководителя: испортился и стал плохо работать. Насколько это оправданное заявление? Мне кажется не очень

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

Почему руководитель предпочитает использовать именно слово испортился?

А кому приятно узнавать, что проблема в нем любимом? Такой позицией руководитель оправдывает себя. Сотрудник испортился сам, без помощи компании. Как кефир, у которого истек срок годности. Был нормальный, а стал плохой. Сам! .

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

Но, все же, как мы узнали с кейса, изначально проблема была в том, что сотрудник был демотивирован каким-то фактором, и это, как следствие, привело к такому состоянию и такому результату. Не он испортился, а его испортили! Сразу на ум приходят слова русского классика М. Ю. Лермонтова: Я был готов любить весь мир, меня никто не понял: и я выучился ненавидеть.

Потери

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

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

Отсрочка, инициируемая руководителем

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

Насколько это правильно? Опять-таки, у меня по этому поводу есть сомнения...

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

Успех практики отсрочки возможен, но будет зависеть от множества разных факторов. Так, если у вас: сильная система управления, сотрудник занимает штатную позицию (не руководящую) и ему не нужно инициативничать, креативить, творить, нестандартно мыслить (попросту говоря - его работа на 100% регламентирована) - это вполне может сработать. Если же нет - от этого будет мало пользы.

Другие кейсы находите в telegram-канале:https://t.me/OS_management

Подписывайтесь! Далее будет...

Приветствую, Хабр!

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

Проблемы традиционного взгляда на бизнес-процессы

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

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

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

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

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

Гибкое управление бизнес-процессами

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

Я представляю процессы НЕ как что-то искусственное, в стиле: "вот мы описали процессы и они начали существовать", а как органическое следствие роста организации, где с каждым шагом по рынку появляются всё новые проблемы и задачи, направленные на их решение. А на основе опыта решения проблем в компаниях появляются "Тропинки действий", которые мы и называем бизнес-процессами.

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

Есть такой термин как Adaptive Case Management. Его еще называют Agile BPM. Суть метода как раз описывает внедрение изменений в задачи на основе полученного опыта, где кейсы это ситуации, с которыми компания сталкивались в прошлом. Если проблема была решена успешно, то оставляем последовательность задач как было. Если проблема была решена плохо, то вносим коррективы и в следующий раз используем другой алгоритм.

Информационные системы и гибкое управление процессами

Когда нарастание сложности компании превращается в корпоративный хаос, менеджеры задумываются о внедрении инструментов, чтобы удержать контроль над системой. И здесь на помощь руководителям призваны различные информационные системы. Причём не важно, идет ли речь об ERP, BI, BPM, CRM, обычные таблицы любой класс этих продуктов для большинства менеджеров разновидность учёта и контроля качества бизнес-процессов. Где-то менеджеры контролируют движение денежных потоков. Где-то контролируют входящий клиентский поток. Где-то контролируют работ, которые выполняют сотрудники.

В гибком управлении процессами информационная система в большей степени не инструмент учёта управленца, а прежде всего инструмент для удобного взаимодействия сотрудников, где они могут сами организовать планирование и учёт в том виде, в котором это удобно для выполнения работы. Это когда-то давно поняли японцы, создавшие для координации и управления целыми заводами простые канбан доски. Сегодня это понимают разработчики таких инструментов как Trello, Airtable, Miro, Notion, Slack, Unicore и других сервисов...на первый взгляд, между этими системами мало чего общего. Но, по-моему, все они решают одну большую проблему предприятий отсутствие общего, удобного и адаптируемого информационного пространства для совместного решения задач бизнеса.

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

Относительно недавно появился термин Work Management System то, о чём я пишу об этом. Софт становится человекоориентированным и гибким, чтобы с помощью него не менеджеры управляли процессами, а сами сотрудники.

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

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

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

Опросы

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

Еженедельный опрос

В конце каждой недели мы получаем опросник на 30 секунд с вопросами: как часто у вас не было сил выполнять работу? Получал ли удовольствие от задачи? Сколько часов переработал? На выходе мы строим график для всей команды в динамике за последние 6 недель и обсуждаем на ретроспективе.

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

Опрос в конце спринта

Тут всё просто, мы за пару часов до ретроспективы всей командой отвечаем на простой вопрос "Как вам спринт"? Тут мы уже преследуем цель разговорить команду. До введения этого опроса, ретроспектива начиналась с молчания и попыток скрам-мастера разговорить людей, что, как правило, заканчивалось "да обычный спринт, ничего такого". Сейчас же команда стала более разговорчивой, больше обсуждают проблем и кидают больше идей.

Опросы раздражают

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

Мотивация

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

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

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

Боли (от выполнения ручной/неудобной работы)

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

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

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

• Опять же посмотреть в Jira и рассмотреть что мы можем делать лишнего, или что уже не актуально и можно упразднить. Например, мы рассматривали релиз-тикеты и пытались понять какие моменты мы можем делать быстрее. Так мы обнаружили, что security scan кода занимал по 20-30 минут, мы подумали, что можно делать всё проще и в итоге сейчас это занимает около 5-10 минут.

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

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

• Изучение будет происходить в паре/тройке. Так и интересней, и если кто-то уйдёт в отпуск - работа не встанет.

• Пары/тройки будут меняться в будущем. Чтобы команда не дробилась на небольшие "кружки по интересам" и оставалась одной командой.

• Внутри пары/тройки нет ограничений на источник обучения. Кому-то могут нравиться курсы с LinkedIn, кому-то с Udemy, а кто-то вообще нашёл крутой разбор темы на YouTube на своём родном языке.

Больше болтовни

Иногда в офисе обсуждение небольшого вопроса у кулера может затянуться больше чем на пол часа и вовлечь несколько человек. Эти живые, неформальные беседы иногда вносят большой вклад в развитие команды и продукта. С уходом на удалёнку таких бесед почти не стало. А если ещё учесть что почти никто из нас ранее на удалёнке не работал - всем было очень трудно делить личное и рабочее время.

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

Также мы заметили, что когда люди включают web-камеру - они более искренне и более разговорчивы. Если вся команда не разговорчива, мы просто используем Wheel Of Names и там уже рандомом выбираем кто будет говорить.

Фидбеки

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

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

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

• Кастомеры задавали вопросы на одни и те же сообщения в логе. Суть в том, что в логе мы печатали что-то вроде "Module: service XXX call, RC = Y, RSN = ZZ". Т.к. это вообще не понятно никому, L2 выстраивали у себя сводную таблицу таких сообщений, чтобы отвечать кастомерам. Если какая-то новая комбинация - то это шло дальше в L3 (к разработчикам). Решением было простым: мы просто написали функцию которая по кодам печатает user-friendly сообщения с полным описанием причины проблемы.

• Кастомеры находили уже пофикшенные баги. С каждым релизом мы не так много внимания уделяли описанию проблем. В итоге, когда пользователь встречал баг, он открывал описания выпущенных релизов и искал там свою проблему - разумеется он там ничего не находил и писал в саппорт. Ребятам из L2 приходилось лезть в нашу Jira и они пытались найти баги, похожие на кастомерские. Решение банально - мы стали лучше описывать баги с их симптомами в релизах. Кастомеры стали меньше писать в саппорт, т.к. находили свои баги в описаниях релизов, а если уж и открывалось, L2 на них почти всегда могли ответить самостоятельно и быстро.

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

Ежедневный отчёт

У нас каждый день скрам-мастер, в конце рабочего дня, в канале команды в слаке публикует суточный отчёт, который описывает текущие горящие темы, блоки команд, проблемы в команде/продукте и т.п. Этот отчёт полезен как для команды, так и для менеджмента. Во-первых, если кто-то из команды имеет проблемы и видит, что его проблема там не описана - он идёт к скрам-мастеру и отчёт обновляется. Во-вторых, все видят что происходит сейчас в команде, у менеджмента есть актуальный, обобщённый отчёт, и им не нужно дёргать людей, чтобы получать ответы на свои вопросы. С помощью этого отчёта мы пытаемся добиться прозрачности и выявлять блоки как можно раньше, чтобы избегать случаев "У нас уже месяц всё хорошо, но 4 недели назад случилась проблема и мы не успеваем".

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

Свои метрики

Внутри команды у нас есть свои метрики. Некоторые пересекаются с менеджерскими, некоторые уникальны.

Например, кастомерские проблемы идут в приоритет и нам, как команде, очень важно, чтобы оно в L3 находилось как можно меньше времени. Поэтому мы стараемся отвечать на проблему, либо находить реальную причину (например, баг) как можно быстрее. Менеджмент всего лишь следит, чтобы ответ был не дольше чем за 2/7 дней (в зависимости от важности проблемы - у них свои метрики).

Частота "незапланированных" задач. Каждый спринт у нас случаются не запланированные таски, возникающие после старта спринта, которые откладывать на 1-2 недели нет возможности. Мы пытаемся отслеживать такие вещи, смотреть сколько в среднем мы тратим на них время и каждый спринт откусывать кусок пирога для этой активности. Тем самым, нам проще выполнять наши собственные коммитменты и тогда команда становится более предсказуемой.

Мы используем и другие метрики, включая самые очевидные: процент покрытия кода юнит-тестами, покрытие QA тестами функционала продукта, время жизни пулл-ревквеста или velocity команды.

Больше правил

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

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

Правила помогают разделять белое и чёрное, избегать конфликтов и иногда упрощать жизнь. А иногда, наоборот, усложняют жизнь. Ввод любого нового правила означает снижение доверия к индивидуумам, снижение доверия означает рост неэффективности, рост неэффективности приводит к увеличению времени разработки.

Также, правила должны подвергаться пересмотру. Например, в какой-то момент времени у нас случилось несколько кастомерских проблем из-за релиза, баги в котором могли быть замечены аж на трёх этапах: Разработка (code review), Просмотр билда разработчиками, и уже QA. На всех трёх этапах можно было предотвратить ошибку. Разумеется, после этого инцидента все этапы были ужесточены. В итоге то, что раньше могло занимать до 5 дней, стало занимать до 10 дней. Со временем все ужесточения были пересмотрены. Некоторые до сих пор остались, просто был изменён процесс чтобы действие занимало меньше времени, что-то было упразднено, а что-то наоборот добавилось.

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

Ответственность на всех

В нашей команде мы стараемся играть в "трёх мушкетёров", т.е. ответственность за всё лежит на ВСЕЙ команде, никто не будет осуждать члена команды вне команды. Если кто-то один облажался и это привело к каким-то последствиям, то всё равно виноваты все, потому что:

• Плохие вещи случаются. Нельзя запланировать и предвидеть всё.

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

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

• Обвинения не решают проблем. Вообще никаких.

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

• Женщину, которая в полной темноте переходила дорогу в неположенном месте?

• Водителя автомобиля с автопилотом, который вряд ли сам среагировал бы?

• Компанию, которая разрабатывает автопилот?

• Разработчиков, кто писал код для автопилота?

• QA кто выпустил этот код в прод?

Субъективно, тут виноваты все, либо никто. Но, очевидно, что виновные есть, т.к. в итоге женщина скончалась. Значит виноваты все.

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

Team Building

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

Заключение

Выбрав фреймворк как Scrum, Kanban, Lean и т.д. глупо надеяться что все проблемы разрешатся, все будут мотивированы, счастливы и довольны. Внутри команды не стоит надеяться, что кто-то другой решит ваши проблемы, особенно, если вы о них не говорите.

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

Привет!

Меня зовут Слава, я технический руководитель направления Застройщики в Циан. Внутри направления работают 25 человек. Из них 18 разработчики и тестировщики. С середины 2019 года мы участвовали в экспериментах по удаленной работе в Циан.

18 декабря я опубликовал статью о переходе на удаленку в Циан. Это ее продолжение.

Наем на удаленке

Жизнь человека в компании начинается с собеседований. Сейчас мы нанимаем сотрудников по всей России. В моей команде работают люди из разных городов (от Калининграда до Омска), некоторые уехали из Москвы во время пандемии, некоторые никогда не были в офисе и прошли процесс найма полностью удаленно. В некоторых командах есть люди, которые работают из других стран.

Наем программистов состоит из следующих этапов:

Диалог с HR

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

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

Техническое собеседование

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

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

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

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

Финальное собеседование

Для всех, кто успешно прошел техническое собеседование и хочет продолжить общение с Циан, назначается последнее собеседование.

Основная цель - это определить риски по кандидату и сможет ли он быть результативным и успешным работая в конкретной команде, какой возможный карьерный путь в Циане. На нем присутствуют лиды команд, которым интересен кандидат, и HR бизнес-партнеры направлений.

Соответствие ценностям компании очень важная характеристика кандидата. При соответствии ценностям новому человеку будет проще влиться в команду и добиться успеха в будущем. и кандидату и нам будет легко и приятно работать вместе.

Наши ценности

• Давай результат. Мы принимаем все решения внутри компании для достижения результата. Любой, даже хорошо отстроенный процесс будет изменен, если он не ведет к результату. Результат чаще всего это продукт, который поменял метрику на значение Х и был запущен к сроку Y. За достижение результата любой человек в Циан готов взять на себя ответственность.

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

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

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

На финальном собеседовании кандидат может задать все вопросы о специфике работы в команде и получить честные ответы. Чаще всего финальное собеседование занимает полтора часа. Заканчивается оно в момент, когда кандидат получил ответы на все свои вопросы.

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

Сбор рекомендаций

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

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

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

Оффер, договор и оборудование

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

Адаптация и испытательный срок

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

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

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

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

Что сработало хорошо?

Деплоймент и технические аспекты отработали хорошо. Эксперименты с удаленкой до пандемии позволили решить большую часть проблем с VPN и окружением до начала массового перехода. (Часть 1)

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

Для посещения офиса появилась система бронирования мест. Всегда можно посмотреть, кто будет в офисе в один день с тобой. При посещении офиса получаешь брендированную маску. (Часть 1)

Над чем работаем?

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

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

• Формат больших встреч. В компании есть большие информационные встречи продуктовое демо, IT-вече (с новостями IT), ежеквартальная встреча с CEO. При переходе в онлайн стало тяжело без обратной связи слушать часовую встречу. Сейчас экспериментируем с форматами так, чтобы во встрече оставалась динамика и слушать ее было интересно.

• Причастность к компании. В формате удаленной работы мало что меняется при работе в разных компаниях. Уходит единое пространство общения. У нас есть запас причастности для тех, кто работал в офисе, эти сотрудники знают, какие интересные люди работают в компании. Как это перенести в удаленку пока непонятно. Работаем над этим.

• Рост внутри компании. Этот вопрос частично закрыт регулярными встречами, но из-за частично потерянной связи между направлениями вопрос становится сложнее.

Итоги

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

Компания хорошо адаптировалась. Все основные процессы для разработки, найма и планирования перенесли в онлайн. Разработчик сейчас может работать из любой точки мира. В нашей команде Застройщики участники распределились по нескольким городам: Москва, Санкт-Петербург, Краснодар, Одесса, Челябинск, Омск, Сочи, Волгоград. Это часовые пояса от GMT+3 до GMT+6.

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

Есть проблемы, над которыми мы работаем. Может быть, у вас есть опыт их решения: поделитесь в комментариях своим опытом, пожалуйста.

Ссылка на первую часть

Работа в режиме завала и в режиме нарастающего завала.

Для простоты изложения возьмем конвейерное производство. Конвейер традиционно делится на участки (на множество участков). На каждом участке конвейера есть сотрудник, который выполняет определенный процесс или занимает позицию наблюдателя - стандартный руководитель. Представим картину: на таком производстве в середине смены, кто-то упустил определенный момент и все, что находится на конвейере падает на пол. Вот тут и начинается Жопа. Все бегают, суетятся и проклинают виновника и в экстренном порядке пытаются придумать что-то.

Логичным чем-то считается варианта два:

1. Останавливаем конвейер и все дружно разгребаем завал.

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

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

А что, если идём по второму пути? Правильно!

Завал растет, а если завал растет, то все участи выбиваются из общего темпа, детали делаются дольше, заказчики становятся злее, начальство орёт и все дружно остаются после смены и разгребают изрядно подросшую кучу, в некоторых случаях не один день!

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

Переведем завод на типичную компанию, предоставляющую IT-услуги:

Конвейер - это отлаженная цепь от хотелки до какой-то крутой штуки для заказчика.

Участки (самая длинная возможная цепочка):

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

2. Менеджер (руководитель проекта) - тот человек, который принимает поток потребностей клиента и определяет путь этой потребности дальше.

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

4. Аналитик - когда есть, когда нету, но нужный человек в таком производстве. Он может также находится на участке 2-3 как человек, который превратит потребность Случайного генератора идей в оформленную задачу и вовремя сказать клиенту Вася, ты болван! Давай думать, а не выдумывать или же может играть роль человека, который скажет вот вам кнопка, давайте проверим так ли хорошо. Такого человека можно назвать технолог на производстве и креативный упаковщик одновременно.

5. Снова клиент - но тут правильнее назвать его Заказчик, потому что он заказал ту самую крутую штуку и ждет что сейчас ему её отгрузят и случится магия. Он же в дальнейшем будет являться службой контроля качества, потому что только его седой голове известно, что он хотел.

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

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

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

3. Программист. Завал задач из-за потока безумства первых двух участков, т.к. первым всегда надо качественно и прям сейчас, а вторых у каждого программиста больше одного. К чему приводит? К тому что программист не делает вовремя или делает вовремя но не следит за качеством решения, что ведет к браку, который вернётся бумерангом через пару дней и шарахнет. Еще и обидным словом обзовут, но ему не до этого..там со второго участка еще 15 прилетело на сделать сейчас и с четвертого вернули 3 из 3, которые сделать успел (тоже щас надо было).

4. Аналитик. Завал потребностей к постановке и завал задач к сдаче. Он бедняга просто проверять не успевает, его то на первый участок дёрнут, то на третьем не всё понятно, то второй придёт с криками, что надо ему помочь он рвётся, то пятый кричит, что он не так хотел (а ты ему говорил блин!) К чему приводит? К сдвигам сроков программистов и нарушению их горизонта планирования, к уплотнению встреч для сдачи работ клиенту, соответственно теряется время на вникание в потребности и отсев неадекватных задач, теряется время на упаковку кнопки и её заменяют на вот вам, пошарьтесь сами, вроде то, а если заказчика оставить наедине, то это 99% возврат и прочие проблемы этого типа.

5. Клиент на пятом участке. А ему просто лень вникнуть прям сейчас, он вникнет когда пригодится, если его вовремя четвёртый участок не дернет. К чему приводит? К ах вы бестолочи, я вас просил еще месяц назад и говорил, что мне срочно надо, а вы уже месяц сделать нормально не можете, я из-за вас от генерального получил по шее и по карману и возврату на участок #3. Теперь понимая возможные завалы подведём итог: Конвейер всегда двигается дальше и чем дальше он двигается тем ближе мы к следующему участку, кто-то создал завал - больше давят обстоятельства в виде того что надо подготовить деталь к следующему участку хотя бы как то и то что следующую деталь надо еще быстрее делать..и так по кругу Особенность сферы IT что почти каждая деталь уникальна и выработать механические действия нельзя, соответственно допустить завал на участке 3 не просто вредно, а критично для всех.

Итак выводы со всей болтовни такие:

1. Если чувствуем завал задач от клиента и это не внедрение, то что-то идет не так. Нужен кто-то кто обработает этот поток, именно обработает, а не запишет на бумажку и отдаст первому попавшемуся программисту. Конкретно берем менеджера или аналитика, даем его клиенту, они садятся и определяют ответы на вопросы "Зачем", "Когда", "Почему именно тогда", может даже это куда-то записывают. В итоге должны получить из кучи "хотелок" нормально выстроенный список задач (или описания задач), с которым уже дальше можно работать. Участок разгружен.

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

Итак: Во-первых, менеджер один не справится с завалом. Дайте ему помощь - еще одного менеджера или аналитика. Во-вторых, задайте себе вопрос: не ли завала от каждого клиента, если есть то начинаем разгребать оттуда. В-третьих, никогда не пытайтесь впихнуть невпихуемое. Это не избавит вас от проблем, только добавит. Ничего страшного предложить клиенту сроки: "через неделю", "через месяц", "через год", или и вовсе отказать, если прям ну совсем никак. В-четвертых, не жалуемся, а решаем проблему. Многие менеджеры когда их задачу не берут идут кому-то жаловаться: своему начальству, начальству программистов, высокому начальству. В итоге если там разбираться не будут то впихнут невпихуемое. Лучше в данном случае собрать обратную связь от программистов и попросить помощи в порядке: "я попробовал обратиться вот туда и вот туда, тут сказали что могут через год, а тут сказали что не хватает компетенций для решения задачи клиента, помогите с решением". И самое главное: не хватайтесь за все и сразу, иначе все это упадет на пол и придавит сверху вместе с вами. Проще говоря, поставят за вами следить какого-нибудь начальника и он будет над вами висеть пока не разгребете весь завал (если вообще разгребете).

3. Если чувствуем завал задач на плечах программиста. Когда у программиста завал, к нему будут бегать менеджеры, он будет прыгать от одной задачи к другой не успевая сделать ничего или делая, но это будет возвращаться десятками итераций. Первое что надо сделать это поставить на стоп все новые задачи. Нет смысла их брать, потому что "надо выполнять план" или "зарплата будет маленькая, потому что мало сделал". Чем дольше игнорируется завал при принятии новых задач, тем меньше вы будете делать и тем больше будете на слуху, а тут могут и задумать о вашем увольнении.. Далее надо все задачи распределить по срочности/важности. Тут можно рисовать всякие квадраты, записывать их в н бумажку и ставить цифры возле них, кому как удобнее. И последнее понять, можно ли что-то передать, если можно то лучше сделайте это.

4. Если чувствуем завал у аналитика. Тут увидеть легко, у аналитика забит календарь встречами, и его поведение становится похожим на поведение менеджера в завале. Так же бегает от программиста к программисту, от клиента к клиенту. Тут важно понять с чем связан завал аналитика. Это может быть из-за завала от клиента/менеджера, тогда в первую очередь надо помочь это разгрести совместно с менеджером / с клиентом. Это может быть из-за завала программиста. Аналитик в таком случае не успевает сдавать задачи и возвращать задачи из-за брака. Здесь важно определить реальные сроки чтобы все сделать и проверить и договориться с менеджером / с клиентом о новых сроках. Ну и это естественно может быть из-за перебора задач. Зовем на помощь еще одного аналитика / менеджера.

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

Вот такие размышления были в моей голове. Жду от вас обратной связи. Слава Хейтерам.

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

Мы в Kolesa Group прошли путь от иерархической структуры управления в матричную. Хапнули багов и пропатчили ее до оптимального, в нашем профиле, состояния.

В статье разберем:

1. Как достичь автономности команд разработки.

2. Как эта автономность помогает нам расти в 2 раза по всем показателям.

Немного контекста

Kolesa Group это классифайды. 4 продукта в 2-х странах (Казахстан и Узбекистан) на 4-х платформах (iOS, Android, десктопный и мобильный web). Начинает свою историю компания с печатного издания. В 20хх году печатное направление было закрыто, и компания целиком сосредоточилась на онлайн-направлениях.

Вся разработка ведет свою историю с веб-направления. Изначально это были fullstack-разработчики в отделе под названием Веб-редакция. По мере роста в компании появлялись сначала админы, потом тестировщики, мобильные разработчики. Разделились на frontend и backend веб-разработчики, и наконец разделились QA на web и mobile.

Немного внутренней кухни

У каждого из направлений есть руководитель, который отвечает за:

• операционные вопросы (отпуск, больничный, найм, увольнение),

• развитие и обучение,

• формирование требований к позиции,

• оценку и грейдирование специалистов,

• техническую стратегию по направлению.

Специалисты разделены на команды по продуктам. А микрокоманды по микропродуктам. В каждой команде есть тимлид: отдельно веб, отдельно мобильный. Также есть менеджер продукта, подчиняющийся руководителю продукта, который в свою очередь подчиняется директору по продуктам.

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

О проблемах и их решениях

Проблема 1. У специалиста появилось несколько начальников.

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

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

Проблема 2. Организационные вопросы.

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

Решение. Сформулировали матрицу ответственности.

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

Проблема 3. Появилась некоторая разобщенность внутри команд.

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

Решение. Ввели роль SEM-а или Software Engineering Manager.

В его обязанности входит обеспечение оптимального процесса разработки продукта всеми (микро-) командами на всех платформах. По сути, это технический директор (CTO) конкретного продукта.

Немного о SEM-ах: какие задачи они выполняют

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

Изменение в воркфлоу команды происходит по цепочке:

Руководитель департамента -> SEM -> Тимлид от департамента -> Юниты

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

Новая роль: тимлиды мобильной разработки

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

Итог

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

Аналоги

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

Так, например, в компании Spotify существуют Engineering Managers.Их основные задачи:

1. Создание, сплочение, лидерство и менторство

2. Найм и увольнение людей в команду

3. Фидбек

4. Ответственность за техдолг и и стратегию команды

5. Сотрудничество с другими инженерами и менеджерами по продуктам для решения интересных и сложных проблем на платформе.

6. Развитие здоровой культуры совместной инженерии, в соответствии с ценностями компании

7. Быть активной частью команды лидеров и сотрудничать с другими лидерами в компании

8. Растить техническую экспертизу команды

Engineering Manager в Badoo:

1. Работает с командой над внедрением новых фич, обучает и развивает команду в направлении гибких методологий.

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

3. Работает с менеджером по разработке и менеджером по продукту, влияя на план развития его продукта.

4. Является гарантом того, что команда создаст решения соответствующего уровня качества.

Я основал компанию Gumroad в 2011 году. В 2015 году у нас было рекордное количество людей - 23 штатных сотрудника с полной занятостью. В 2016 году, после неудачной попытки поиска финансирования, я вернулся в точку, с которой начинал. В компании снова был всего один сотрудник - я сам.

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

Если посчитать всех, кто работает в Gumroad, получится 25 человек.

Если считать штатных сотрудников с полной занятостью, то их нет. Даже я не отношусь к их числу.

У нас нет совещаний и нет дедлайнов.

И этот подход работает: наши авторы зарабатывают более 175 миллионов долларов в год, а компания в среднем зарабатывает 11 миллионов долларов в год, и эта цифра растет каждый год в среднем на 85%.

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

Свобода любой ценой

После массовых сокращений в 2015 году компания Gumroad продолжила расти, несмотря на потери среди персонала.

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

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

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

Тем временем я переехал в Юту и пытался работать в качестве полноценного автора контента.

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

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

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

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

Как мы работаем

На сегодняшний день работа в Gumroad похожа на работу в проекте Open Source, например, таком как Rails. За исключением того, что это не Open Source, и эта работа оплачивается.

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

Все пишут хорошо, и пишут много.

Никаких дедлайнов у нас тоже нет. Мы постепенно улучшаем сервис и выпускаем обновления, когда версия, которая находится в разработке, становится лучше, чем текущая версия. Есть исключения, например, строго установленные сроки подачи налоговых деклараций, но обычно я стараюсь не говорить никому, что им делать и с какой скоростью. Когда в компании появляется новый человек, он делает то же, что и все: заходит в наш канал в приложении Notion, берёт задачу и приступает к ее выполнению, обращаясь к коллегам за разъяснениями, если необходимо.

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

Но мы не ставим жестких рамок и приоритетов.

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

Точно таким же образом мы работаем над масштабными задачами.

В ноябре 2020 года мы запустили проект Gumroad Memberships, который действует уже год и благодаря которому сотни авторов, использующих новую систему, зарабатывают более 1 500 000 долларов в месяц.

Ниже приведен скриншот из нашей дорожной карты, чтобы показать, как это выглядит на практике:

Также я записал часовой видеоролик о том, как мы работаем над созданием такого масштабного проекта, как Gumroad Memberships.

По словам разработчика Gumroad Хелен Худ, которая работала над созданием Memberships: "Это был один из самых масштабных запусков продукта за всю мою карьеру, и мы сделали этот проект без единого митинга или видеозвонка. У меня есть опыт работы в обычном стартапе с известной всем корпоративной культурой - открытый офис без дверей, множество белых досок, стендап-митинги и планирование спринта, пиво с коллегами после работы. Также у меня был проект, где все работали удаленно, было мало коммуникации, и программисты в основном работали каждый над своей задачей, они не были одной командой. Для меня то, как мы работаем в Gumroad - это идеально. Это позволяет мне с максимальной пользой использовать часы, когда я продуктивна, и заканчивать работу, когда я достигла своего предела".

Это весьма краткое описание, но мы опубликовали еще несколько статей, в которых подробно описано, как мы работаем:

• Как мы решаем, над чем работать? "И конечно, нельзя не отметить, что в Gumroad вкладывается очень много эмоций, этим он ничем не отличается от других арт-проектов. Иногда мы выбираем то, что интересно и над чем нам нравится работать! Мы любим прислушиваться к авторам! Мы никогда не проводим масштабный анализ данных, чтобы решить, над чем стоит работать дальше".

• Как мы общаемся? "Отключите все уведомления в телефоне!"

• На что похожа работа в Gumroad?

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

• Есть ли негативная сторона у работы в Gumroad? "В компании не так уж много возможностей для роста. Компания приносит доход, и мы не планируем увеличивать команду каждый год и набирать много людей. Хотя у нас скорее всего и будут руководящие должности, их немного, и они не являются ступенькой какой-либо внутренней карьерной лестницы, по которой мог бы двигаться сотрудник Gumroad".

Сотрудник Gumroad Крис Максимин сообщает: "Этот принцип работы позволил мне достичь наибольшей продуктивности, которая у меня когда-либо была. Возможность сконцентрироваться только на работе и на том, что действительно важно, создает благоприятный цикл взаимодействия, который приносит положительные результаты и компании, и сотрудникам: 1) компании не нужно платить огромные зарплаты программистам за то, что они часами сидят на бесконечных и бесполезных митингах, и 2) программисты могут сделать больше задач и научиться многим вещам, что принесет им огромную пользу в долговременной перспективе".

И так работают не только программисты.

Джастин Миколай, занимающийся написанием текстов в Gumroad, точно так же работает над каждой публикацией Creator Spotlights, хотя над каждой статьей трудятся минимум три человека, плюс создатель контента.

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

Мы не можем конкурировать с другими крупными компаниями

Такой способ работы не для всех.

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

Но мы можем конкурировать (и выигрывать!) за счет нашей гибкости.

Сид Ядав, ранее занимавший должность вице-президента по продукту в компании Teachable, стал частью команды Gumroad в 2018 году.

По его словам: "У большинства предпринимателей есть два варианта: они могут работать на полной ставке, а своим делом заниматься по вечерам или на выходных, или уйти с работы и рискнуть всем, чтобы основать свою компанию. Gumroad предлагает третий вариант: я могу работать на договорной основе 20-35 часов в неделю, или пару дней в неделю, воплощать свои идеи и затем работать над своим следующим проектом".

В 2020 году Сид ушел из компании и вместе со своим бывшим коллегой из Gumroad Руди Сантино основал свою собственную компанию Circle, которая также предоставляет площадку, где авторы могут продавать свои работы и услуги.

Работа в Gumroad не является ни для кого главным приоритетом и основным способом самореализации.

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

Программист Нэйтан Чан, работающий в Gumroad, рассказывает: "За всю мою карьеру именно здесь у меня значительно больше времени для по-настоящему важных вещей в жизни, чем у меня было, когда я работал в других компаниях. Я могу полноценно участвовать в воспитании своих детей и смотреть, как они растут".

Я тоже разделяю эту точку зрения.

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

Компания авторов контента

Однажды совершенно неожиданно я получил электронное письмо от Дэниела Вассалло. Я знал Дэниела; он является автором, который меньше чем за год заработал в Gumroad более 250 000 долларов.

Он был пользователем нашего сервиса, так что имел представление о том, какие задачи стоят перед компанией Gumroad и что необходимо улучшить, и у него было несколько идей о том, как он мог бы в этом помочь:

Я люблю Gumroad (и я зарабатываю себе на жизнь с его помощью!), мне нравится заниматься разработкой стратегий и постановкой задач. Думаю, я мог бы заниматься проект-менеджментом в Gumroad. В среднем я мог бы уделять этой работе всего 2 часа в день, но я буду доступен каждый день. Не знаю, готовы ли вы пойти на такие условия, но я подумал, что если кто-то и может на такое согласиться, то это Gumroad :)

Он подходил нам идеально. Дэниел стал нашим новым менеджером по продукту.

Для Gumroad это тоже было выгодным предложением. До того, как Дэниел ушел из компании Amazon, он зарабатывал более 400 000 долларов в год. Мы же платим ему 120 000 долларов в год.

Как это возможно? У нас он работает 10 часов в неделю. По его словам:

Зарплаты

Фактически у нас почасовая оплата для всех сотрудников, и размер ставки зависит от занимаемой должности. Зарплаты варьируются от 50 долларов (специалист поддержки) до 250 долларов (менеджер по продукту) в час.

Недавно я установил стандартные зарплаты для локаций по всему миру:

Зарплата обсуждается во время прохождения собеседования:

1. Подача заявки через форму.

2. Неоплачиваемое тестовое задание на несколько часов, которое похоже на одну из сложных задач, над которыми мы работаем в Gumroad. Задание может включать в себя разделение большого проекта (как Gumroad Memberships) на мелкие подзадачи, планирование схемы для нового функционала, или написание статьи для центра справки и поддержки.

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

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

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

Больше нет никаких бонусов, за исключением гибкости и зарплаты.

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

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

После того, как Дэниел присоединился к нашей команде и стал менеджером по продукту, работая на четверть ставки, с нами также стала работать Рэндалл Калла, заняв должность комьюнити-менеджера на четверть ставки, а Филип Кьели стал менеджером по маркетингу на четверть ставки. Все они также являются успешными авторами в Gumroad.

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

Именно такой должна быть работа в экономике творчества.

Будущее работы в том, чтобы не работать

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

Никто не согласился.

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

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

На главной странице Gumroad перечислены преимущества, которые есть у авторов, которые пользуются платформой: "Избавьтесь от офисной работы с 9 до 5. Снимите костюм и галстук. Больше никаких поездок на работу. Зарабатывайте на своем творчестве".

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

Познакомьтесь с командой Gumroad:

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

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

Что поменялось с того времени? Сменились поколения, изменились технологии, изменился уровень жизни... . Но, проблемы сотрудничества остались прежними. Сотрудники продолжают нуждаться в регулярном поощрении (и регулярно его недополучают), а руководители продолжают игнорировать эту потребность. Это было до Тейлора, и это есть сейчас...

Смысл стараться?

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

Когда компания, в лице руководителя, не замечает и не признает успехов, это приводит к таким последствиям:

1) Сотрудники не видят смысл повторять те действия, которые привели к сверхрезультату

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

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

2) Лучшие сотрудники получают демотивационный разряд

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

3) Обычные сотрудники не видят смысл подтягиваться к уровню результатов лучших сотрудников

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

Почему руководители недостаточно хвалят сотрудников?

1) Не считают это нужным

К сожалению, несмотря на состояние рынка труда, боссы продолжают жить в парадигме: Это их работа, они за нее деньги получают. Да, это "их работа", но они ее могут делать по-разному. Можно просто выполнять указания (что сказали - то и сделал), а можно: помогать, подсказывать, показывать недочеты, предлагать новые решения, влиять на процесс и результаты, проявлять инициативу,... . Это тоже входит в их работу?

2) Стесняются

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

3) Бояться, чтобы сотрудники не возомнили о себе много и не попросили больше денег

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

Да, такой расклад возможен. Но, возможен при условии, что сотрудник, либо не понимает ценообразования оплаты своей позиции, либо вы ему реально недоплачиваете (по рыночным расценкам), либо он неадекватен. Если сотрудник не понимает ценообразования - объясните, если вы ему недоплачиваете - доплатите, если неадекватен - поступите, как считаете правильным. Но, независимо от ситуации, вам нужно что-то предпринять, иначе он уйдет.

О нематериальном аспекте

Как показывает практика, нематериальные поощрения успешно подменяют материальные, и сотрудники готовы пожертвовать небольшой разницей в оплате, в пользу компании, которая их ценит и регулярно хвалит. Здесь у меня статус, любят, хвалят...а там мне будут платить на 2000 больше, но еще непонятно, как будут относится - так размышляя, сотрудник сильно задумается. Кроме того, если на сотрудника внутри компании не воздействуют разного рода демотиваторы, он вряд ли начнет мониторить рынок труда и смотреть, сколько где платят. Ему здесь хорошо!

Если мы не можем платить больше?

Допустим, что, все-таки, вы недоплачиваете сотруднику, и вы оба об этом знаете. В таком случае, у вас есть три варианта:

1) Ничего не предпринимать и всячески уходить от обсуждения этого вопроса

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

2) Почаще ругать, поменьше хвалить

Можно пойти по стандартному пути: почаще ругать и поменьше хвалить. Тогда, возможно, сотрудник подумает, что он не такой классный и не захочет уйти.

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

3) Разделить вопросы вознаграждения и поощрения

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

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

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

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

Больше полезностей находите в telegram-канале

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

Кроме профессионально и логично разработанного списка кросс-продаж, всем сотрудникам сети (фармацевтам) было проведено обучение по продажам и разработаны скрипты.

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

Руководство задумалось и начало анализировать ситуацию. Оказалось, что фармацевты не хотят делать кросс-продажи, так как они это считают морально неправильным и даже бесчеловечным. Они говорили: Основная масса наших клиентов - пенсионеры, мамочки и далеко не богатые люди. У большинства из них нет денег на то, чтобы купить все лекарства (они вместо пачки берут пластинку, потому что сразу не могут заплатить за пачку). И мы всем им должны впаривать сомнительные витамины?

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

Увольнения закончились, продажи пошли в гору

________________________________________________

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

• любовь;

• семья;

• дружба;

• честность;

• понимание;

• уважение;

• толерантность;

• терпение;

• прощение;

• благодарность;

• сострадание.

Все эти ценности можно объединить в одно понятие - мораль.

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

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

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

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

________________________________________________

Когда возникают ситуации с расхождением по ценностям:

1) Целенаправленное решение руководителей

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

Компании с не благими ценностями, понимая, что сотрудники не придут добровольно работать к ним, скрывают детали работы и устраивают конвейер. Набирают сотрудников -> быстро обучают -> сотрудники, проработав месяц-второй, начинают понимать, что деятельность компании не совсем честная, увольняются. Таким образом, компании держатся за счет такого краткосрочного сотрудничества.

2) Ошибка рекрутера

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

3) Не подумали об этом

Самая популярная ошибка. Руководители, принимая решение, просто не учли этот риск. В примере с аптечной сетью произошла именно такая ситуация. По этой причине, были потеряны время, деньги и люди (которые покинули компанию).

4) Не объяснили сотрудникам

Когда в компании реально продается вредный продукт или используются вредные алгоритмы его производства, тогда у сотрудников возникает естественное сопротивление на уровне морали. Оно обосновано. Но, ведь бывают еще ситуации, когда сотрудники думает, что продукт вреден, а на самом деле это не так. Например, он не мог не до конца разобраться в вопросе или ему кто-то неправильно обьяснил или ему так показалось . Сотрудник сам себя накрутил. В таком случае, получается самый печальный вариант: сотрудник необоснованно считает компанию некорректной и аморальной.

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

________________________________________________

Итоги

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

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

Продолжение серии кейсов о демотивации и другие кейсы о менеджменте находите в telegram-канале: https://t.me/OS_management

Подписывайтесь! Далее будет...

Проблематика

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

Какие есть варианты?

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

В чем смысл объединения?

1. Заходить в 5 досок и просматривать отдельно каждого, просто не хватит времени и сил.

2. Если не синхронизировать доски на одном экране, будет крайне сложно сравнить одного сотрудника с другим по уровню текущей нагрузки.

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

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

Как синхронизировать доски 5 сотрудников в одной доске "дашборде" и при этом не оплачивать лицензию в Трелло или передаточных сервисах типа Zapier?

Решение задачи:

К счастью для работы с досками trello уже создан полноценный пакет на языке R, который позволяет подключаться к API таскменеджера, и именно им я и решил воспользоваться для решения всех задач.

Ход решения:

Сначала получим ключи и секретный код для работы с API https://trello.com/app-key (предварительно необходимо авторизоваться под своей учеткой в Trello и открыть себе доски сотрудников с правами администратора)

Сохраняем ключ и токен, который можно найти внизу этой же страницы

Далее установим сам язык R. Для его подключения нужноскачатьи установить инсталляторы. Также для комфортной работы с R рекомендуюиспользоватьбесплатную среду разработки RStudio.

Для решения вышеописанной задачи нам потребуется установить пакеты для:

• работы с API Trello trelloR

• работы со временем и временными периодами lubridate

• работы с таблицами и агрегации данных dplyr

Чтобы установить пакеты из основного репозитория CRAN примените базовую функцию install.packages, а для загрузки пакетов с github функцию install_github:

remotes::install_github("jchrom/trelloR")install.packages("lubridate", dependencies = TRUE)install.packages("dplyr ", dependencies = TRUE)

Подключаемся к API и получаем токен:

# Указываем путь к папке куда будет сохранен полученный tokensetwd("C:\\*********\\R_script\\trello")# Получаем tokenmy_token = get_token("my_app", key = "", secret = "",                     expiration = c( "never"))

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

trelloadd <- function(delcard = NULL,                      addcard = NULL,                      nlista = NULL){  # Находим исходный лист сотрудника в Трелло откуда будем брать карточки  для записи в дашборд  ishod_tab <- get_list_cards(addcard)    # Определяем доску куда пишем новые карточки  bid = get_id_board(delcard)    # Получаем все списки с листами на доске дашборда  lid <- get_board_lists(bid)$id[nlista]    # Получаем все карточки в необходимом листе куда пишем  cid<-get_list_cards(lid)    # Удаляем карточки, которые уже есть в листе сотрудника на дашборде  if (length(cid$id)>0) {    for (i in 1:length(cid$id)) {      delete_resource(resource = "card", id = cid$id[i])    }  }else{    print("no-del")  }    # Находим дату создания карточки в исходном листе  dateList<- data.frame(dateadd = NA)  for (i in 1:length(ishod_tab$id)) {    cardID <- ishod_tab$id[i]    dateList[i,1] <- strtoi(strtrim(cardID, 8), 16L)  }  dateList$dateadd <-as.POSIXct(dateList$dateadd, origin = "1970-01-01")    # Циклом собираем лист записи и создаем карточку для переноса в дашборд  if (length(ishod_tab$name)>0) {    for (i in 1:length(ishod_tab$name)) {        payload = list(        idList = lid,        name = ishod_tab$name[i],        desc = paste0(ishod_tab$desc[i],"Date Add: " ,dateList$dateadd[i], "                     В работе уже ", floor(as.vector(difftime(today(),dateList$dateadd[i], units='days'))), " день"),        start = ishod_tab$start [i],        due = ishod_tab$due [i],        pos = "bottom"      )      r <- create_resource("card", body = payload)    }  }else{    print("Ok")  }  if (nrow(bind_rows(ishod_tab$labels[]))>0) {      # Добавляем лейблы (метки)    bid = get_id_board(delcard)    lid <- get_board_lists(bid)$id[nlista]    cid <-get_list_cards(lid)        # Находим карточки без меток    nlab <- which( lapply(ishod_tab$labels, length)!=0 %in% T)    for (i in nlab) {      labl <- ishod_tab$labels[[i]]      for (xi in 1:nrow(labl)) {        r <-  add_label(cid$id[i], color = ishod_tab$labels[[i]][xi,4],                        name = ishod_tab$labels[[i]][xi,3] )        }    }   }else{    print("no_lable")  }}

В функции необходимо будет только заполнять переменные:

• delcard - Это id дашборда в который будет записываться информация из досок сотрудников

• addcard - Это id листа из которого будут браться карточки для переноса в дашборд

• nlista - номер листа в дашборде в который будут заноситься карточки

Получаем delcard

Для получения id дашборда куда будем писать общие карточки, сначала необходимо создать эту доску в самом Трелло, а затем из поисковой строки браузера скопировать необходимый нам id

Получаем addcard

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

get_board_lists("https://trello.com/b/*****/сотрудник1", query = list(customFieldItems = "true"))

В результате выполнения функции, прямо в консоли R мы получим перечень всех листов на доске и по названию листа можем выбрать необходимый нам id для получения карточек

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

Далее проходим доски всех сотрудников и перезаписываем их на общий дашборд используя функцию созданную выше:

# Сотрудник1 ####trelloadd(delcard = "od*****W",           addcard = "600**********04",          nlista = 2)# Сотрудник2 ####trelloadd(delcard = "od*****W",           addcard = "5fc4********24",          nlista = 3)# Сотрудник3 ####trelloadd(delcard = "od*****W",           addcard = "5e94*********8ce",          nlista = 4)# Сотрудник4 ####trelloadd(delcard = "od*****W",          addcard = "5faa*********c522",          nlista = 5)# Сотрудник5 ####trelloadd(delcard = "od*****W",          addcard = "60744*******3394",          nlista = 6)# Сотрудник6 ####trelloadd(delcard = "od*****W",          addcard = "5e73******b07",          nlista = 7)

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

В итоге:

1. Мы получили полноценную синхронизацию всех досок любого числа сотрудников в trello

2. Решили проблему с тем, чтобы наглядно иметь доступ к дате создания каждой задачи

3. Имеем фундамент для анализа продуктивности сотрудников в любых разрезах, благодаря возможности добавлять в код новые различные улучшения расширяя код на основе Api от Trello, на основе бизнес логики вашей компании и возможностей языка R.