Напоминаю: мы делаем кейс для отдела разработки 1С:Франчайзи, который позволит увеличить выработку вдвое. Начало - здесь.
Читатели несколько раз сделали замечание, что кейс похож на сериал, и цель его не понятна. Замечание принимаю, учитываю, обозначаю границы. Всего статей будет четыре, максимум – пять. В первой обрисована цель, среда и ее ключевая проблема, во второй (this) будет подготовительная часть кейса (что надо сделать), в третьей будет вторая часть кейса (что надо делать), в четвертой будет метакейс – особенности внедрения кейса. Возможно, будет пятая, уточняющая непонятные моменты, обозначенные читателями.
Самая сложная часть – внедрение – оставлена напоследок. Не потому, что сложная, а потому, что вариативная. Во-первых, я не знаю, кто вы. Вы можете быть собственником франча, руководителем во франче, программистом-чемпионом, программистом средней руки, новичком, троллем, посторонним, эльфом и т.д. Во-вторых, процесс внедрения зависит от того, кто вы. В-третьих, сам кейс, т.е. что именно вы будете внедрять, зависит от того, кто вы.
В этом прелесть бизнес-программирования, и его же проблема. Хочется, как в книгах по менеджменту, сказать – так, ты берешь вот это, тащишь туда, сидишь здесь, делаешь то, а самое лучшее – ТОС (или Scrum, или Lean, или еще что-то). Бизнес-программирование смотрит на проблему максимально широко, и говорит, что одного и того же результата можно добиться несколькими путями.
В распоряжении у нас пять составляющих отдела разработки, на которые мы можем влиять: цель, система мотивации, автоматизация, система управления, процессы. Удвоить выработку можно, работая только с одной составляющей – причем, любой. Какая-то быстрее, какая-то медленнее, но сработает каждая. Хотя, решать задачу в реальности только, например, через автоматизацию можно, наверное, лишь «на спор» – как проехать через город на машине задним ходом. Интересно, увлекательно, будет, о чем рассказать, но не эффективно.
Например, если вы – настоящий программист-чемпион, то дальше можете не читать, потому что за двое суток, прошедшие с первой публикации, вы уже увеличили выработку вдвое. Хотя нет, читайте, тогда вчетверо прирасти сможете. Настоящих чемпионов – процента 3, не больше. Причем, от общего числа тех, кто считает себя чемпионом.
Это как раз «проехать задним ходом» - увеличение выработки через изменение цели, т.е. воздействием на одну составляющую бизнес-системы.
Если вы – программист в команде, и хотите внедрить кейс, и у вас есть начальник, которому это не интересно, то вам нужно работать через цель, процессы и автоматизацию. Мотивация и система управления для вас закрыты. Хотя нет, внутренняя система управления, все-таки, в вашем распоряжении.
Если вы – начальник или собственник, то вам доступны все рычаги. Это и хорошо, и плохо, потому что вам придется выбирать и комбинировать. Можно поменять процессы и систему управления, поставить жесткого начальника и внедрить систему силой. Можно изменить систему мотивации, убрать начальника вообще, и все случится само.
Собственно, в этом и состоит вариативность внедрения – я не знаю, кто вы, какие у вас возможности, и какой дорожкой вы двинетесь к удвоению выработки.
Сейчас я просто изложу кейс – что надо сделать, и что надо делать. Сделать – это подготовительная, разовая, проектная работа. Делать – это ежедневная рутина. Сначала дам общий перечень, потом кратко расшифрую, как и зачем.
Кейс
Для кейса я выбрал методы, которые, по моему разумению и опыту, наиболее подходят для достижения цели – удвоения выработки. Вообще, методов в разы больше, но мы тут не писаниной занимаемся, а делом. Также, стоит отметить, что для удвоения выработки не обязательно внедрять все методы – зачастую достаточно какого-то одного.
Разница в начальных условиях – ваших – о которых я ничего не знаю. Наверное, есть на свете самый дебильный франч, у которого самая низкая выработка на сотрудника. Вы – не из этого франча, поэтому ваша метрика выше. А вот насколько выше – понятия не имею. Но то, что выработку у вас можно удвоить – факт.
Итак, что нужно сделать:
- Выбрать, автоматизировать и внести начальные остатки в систему оценок;
- Автоматизировать и внести начальные остатки в систему компетенций;
- Принять решение по системе мотивации, автоматизировать;
- Выбрать параметры стратегии компетенций;
- Назначить дежурного;
- Поговорить с программистами.
Делать:
- Общее обсуждение входящих задач;
- Выбор исполнителя по компетенциям в соответствии со стратегией;
- Управление взаимопомощью и ее учет;
- Управление статусами задач.
Теперь кратко изложу каждый пункт. Но сначала – пояснения по автоматизации.
Автоматизация
Пункт, который присутствует почти во всех вариациях кейса – автоматизация. Все изменения, которые вы будете вносить в процессы, управление и мотивацию, нужно быстро автоматизировать.
«Быстро автоматизировать» - это реально быстро, т.е. в течение дня (включая ожидание возможности обновить конфигурацию базы данных). Отсюда сразу вырисовывается необходимость выполнять эту автоматизацию силами той же команды, выработку которой вы увеличиваете. Если вы – большой франч, и внутренней автоматизацией у вас занимается другой, не подвластный вам отдел, то вам не очень повезло, но выход есть – тайная автоматизация.
Для всего, что есть в кейсе, хватит изготовленной на коленке самописанной конфигурации. Потом, когда-нибудь, вы ее улучшите, встроите в вашу корпоративную систему, сделаете эргономичный интерфейс и т.д. Сейчас нужны практически голые данные. Поэтому, если у вас нет доступа к доработке общей системы, сделайте свою и расшарьте команде.
Если у вас система управления задачами не на 1С, то вам, увы, не повезло – ее, скорее всего, придется в итоге выкинуть. Или использовать как прокси для 1Сной, если в ней торчат клиенты – пусть вбивают задачи туда, а вы пока сделайте себе систему сами, на 1С, и закачивайте в нее данные. Иначе ничего не получится – разработчики bitrix24, JIRA, Github и прочих систем, я прошу прощения, срать хотели на ваши потребности. Если доп. свойство к задаче там еще добавить можно, то табличную часть – вряд ли, а тем более – отчет.
Для автоматизации работы внутренних команд, сидящих рядом друг с другом, лучшая платформа, увы, 1С.
Система оценок
В первой статье мы обсудили, что нам нужна новая система оценок – задачу, которую мы сейчас делаем за 2.5 часа, мы должны делать за 1.25 часа, а продавать за 2.5 часа. Получается, у задачи в нашем целевом состоянии будет две оценки – 2.5 и 1.25 часа. Одна – реальные затраты времени, другая – некая оценка для клиента. Сейчас, в текущем состоянии, считаем, что эти оценки равны (в среднем).
Держать две оценки в одной единице (часах) лично мне не нравится, поэтому я рекомендую систему из Scrum – покер планирования. Каждая задача оценивается в баллах, взятых из ряда Фибоначчи – 1, 2, 3, 5, 8, 13, 21, 34 и т.д. Оценка отражает ваше комплексное видение этой задачи – и сложность исполнения, и трудозатраты, и неизвестность, и проблемность клиента на сдаче работ.
Проще всего начать с «якоря» – определить, что есть задача в 1 балл. Это – самая простая, атомарная задача, из тех, что вы решаете. Соответственно, задача в 2 балла – сложнее вдвое.
Оценки ставятся при обработке входящего потока, т.е. при появлении новой задачи. Каждый участник команды ставит свою оценку, в итоге имеем – 5 оценок (для описанного нами примера). Если есть оценки, расходящиеся более, чем на один элемент ряда, то надо поговорить и понять, почему такая большая разница, ну и устранить ее – либо один переоценил, либо другой недооценил. Когда все разногласия решатся, считается средняя (сумма оценок разделить на количество оценок) – она и будет оценкой задачи.
Если вы внедряете систему «сверху», то вполне можно не устраивать голосований, а ставить оценки самому. У нас не Scrum, правила пишем сами.
Если в процессе решения задачи выяснилось, что оценка занижена или завышена, то можно смело ее поменять. Разумеется, к моменту закрытия задачи итоговая оценка должна быть известна.
Оценка должна быть занесена в систему, и храниться в виде реквизита задачи.
Если вам не нравятся баллы, то можно использовать какой-то вариант нормо-часов. Я такой вариант не рекомендую, но мое мнение можно игнорировать. Например, на заре практики я придумал такую оценку, как «по лучшему» - сколько часов потратил бы на решение задачи лучший программист, который все знает о задаче, контексте, клиенте, функционале и т.д.. Все, что надо такому «лучшему» - написать код.
Теперь крайне важно ввести начальные остатки – оценить задачи за 1-2 месяца, которые вы уже решили, и внести оценки в систему. Во-первых, потренируетесь и выработаете свою систему оценок. Во-вторых, и самое главное – получите текущую скорость и «цену балла».
Например, получится, что вы продаете в месяц 500 часов по 2000 рублей, и это – 500 баллов. Тогда ваш балл на данный момент стоит 2000 рублей. После внедрения изменений вы должны генерировать 1000 баллов, продавать их по 2000 рублей и получать доход вдвое больше (и компания, и сотрудники).
Начальные остатки крайне важны, потому что без них вы не ответите на элементарный вопрос – получилось или нет?Не поленитесь, пожалуйста.
Будет соблазн не оценивать старые задачи, а начать с новых. К сожалению, динамика изменений такова, что вы можете выйти на удвоение выработки через месяц, и через месяц же научитесь работать с оценками. В таком случае вы будете свою удвоенную выработку продавать за прежнюю сумму – обманете сами себя.
Если вы внедряете систему «сверху», то идеальный вариант – сделать ввод начальных остатков тайком от программистов.
Система компетенций
Система учета компетенций настолько важна, насколько и не распространена. Записи о количестве сертификатов, разумеется, системой учета компетенций не являются (равно как и сертификаты не являются компетенциями).
Компетенции – это иерархический справочник. Его структура и детализация полностью зависит от ваших потребностей и трудолюбия. Мельчить не надо, потому что замучаетесь данные вводить. Просто определите, что для вас важно в компетенциях, что реально нужно знать.
Аналитики у компетенций две – задача и человек. Ими и руководствуйтесь при наполнении справочника – ответы на вопросы «каких компетенций требует задача» и «какими компетенциями владеет человек», выданные системой, должны вас устраивать.
Я делил компетенции на две принципиальные части – технику и методику. Техника – это про программирование и платформу. Например, работа с внешними источниками данных, или обмен с битриксом, или сложные схемы компоновки данных. Методика – это конкретные подсистемы, документы и разделы учета. Например, закрытие месяца в УПП, бюджетирование, управление заказами, диспетчеризация производства и т.д. Можно воспользоваться моим опытом, можно создать свой.
В информационной системе, в объекте задачи должна появиться табличная часть – компетенции. В ней перечисляются элементы справочника, и ставится оценка. Что за оценка – не знаю, вам решать. Сам я ставил единичку, и считал компетенцию уверенной после набора 10 единичек. Вы можете ставить проценты, и считать компетенцию подтвержденной, если набралось 100 %.
Дальше все понятно. Можно ввести остатки по старым решенным задачам. Во всех новых задачах надо эту таб.часть заполнять. Ну и надо, чуток попозже, посадить программистов, чтобы они нарисовали лепестковую диаграмму и еще кучу отчетов по компетенциям.
Можно добавить в систему документ «План компетенций», в котором вы перечислите приоритеты развития и должный уровень компетенций. Ну и отчет в придачу, который план-факт сделает. Особенно интересно смотреть дисперсию роста компетенций – вполне возможно, что ваш чемпион работает только по основной, или единственной, изученной области, просто популярной в данный момент.
Да, как вы поняли, такая система будет измерять только реальные компетенции – те, что были подтверждены решением задач. Сертификаты, курсы и сказки на собеседовании – это не про нас.
Система мотивации
Этот пункт – только для начальников. В принципе, сдельная система мотивации, когда программист получает, по сути, процент с работ, вполне приемлема (по сравнению с системами мотивации в других профессиях). Но есть минусы, о которых я говорил в первой публикации – подталкивает к индивидуализму.
Решений может быть несколько, я предлагаю самое простое – КТУ. У вас в задаче есть реквизит «Исполнитель», к нему надо добавить табличную часть «Исполнители», тогда все встанет на свои места.
Реквизиты таб.части – сотрудник и процент. Соответственно, начисление за задачу идет не одному человеку, а нескольким (обычно не более двух). Сумма та же, только делится в процентном соотношении, т.е. компания ничего сверх не платит.
Такая система часто встречается у продавцов, когда один, например, притащил клиента, а второй сопровождал сделку.
В нашем случае основной мотив использования КТУ – «раскрутить» чемпионов, да и вообще всех, на сотрудничество. Допустим, человеку досталась задача, а он плохо разбирается или в технике, или в методике, или во всем сразу. Но знает, что другой парень решал подобную задачу (или не знает, а уверен – если посмотрел отчет по компетенциям).
Тот второй, вроде бы, может помочь, но ему нет никакого резона, кроме «помоги по-братски». Исполнитель, в итоге, может потратить на задачу 10 часов, хотя она решается за 2.
Теперь же будет по-другому. Исполнитель подходит к «знающему», предлагает сотрудничество. «Знающий» говорит – там делов на пару часов, у меня и пример есть, надо немного доточить, и все. Сколько хочешь? – спрашивает исполнитель. Ну, давай 30 % - говорит «знающий». Исполнитель соглашается, за 15 минут получает наводку и ликбез, а заодно и примеры кода, решает задачу за 2 часа, получает 500 р. 2 ч. 60% = 600 рублей, т.е. на этом отрезке лично для себя он сработал по 266 рублей в час (600 рублей за 2.25 часа). Если бы делал сам, сработал бы по 100 рублей в час (потратил бы 10 часов, получил бы 1000 рублей).
«Знающий» сработал по 1200 рублей в час (потратил 15 минут, получил 300 рублей). Ну, на то он и знающий. Обычные работы, т.е. свой труд и свое время, он продает по 500 рублей в час, а свои реальные знания – по 1200 рублей в час. Никто не в минусе, большинство – в плюсе. Клиент получил решение быстро, ничего не потеряв в деньгах. Компания ничего не потеряла в деньгах, получила двух довольных сотрудников и довольного клиента. Исполнитель рад до ушей, а знающий, наконец-то, начал получать дивиденды от своих инвестиций в самообразование.
Понятно, что все пропорции будут варьироваться. Иногда знающему понадобится час на объяснение, а иногда – одна минута. Исполнитель тоже, когда за 2 часа сделает, когда 5 все-таки протупит. Но, тем не менее, средний выхлоп будет положительным, и весьма значительным.
Главное, на мой взгляд – полностью отдать распределение процентов программистам, и не вмешиваться в него. Пусть сами договариваются, они – взрослые люди.
Второе главное: если вы – начальник, то не пытайтесь забирать вот эти «халявные» часы у чемпионов. Есть ведь такой соблазн – заплатить только исполнителю, да еще и с понижающим коэффициентом за тупость. Мы в первой публикации договорились, что процент ФОТ не меняется – ни в плюс, ни в минус. При сохранении процента и удвоении выработки компания и так получит своё.
Стратегия по компетенциям
Раз у вас будет система реального учета компетенций, надо решить, как ей пользоваться. Принципиально вектора два – раздавать задачи тому, кто умеет их делать, и тому, кто не умеет.
Первый вектор дает максимальную скорость решения, но не дает развития компетенций. Второй вектор дает минимальную скорость решения, но максимальный рост компетенций.
Понятно, что лучший путь – где-то между векторами. С одной стороны, У нас бизнес, а не университет, и заниматься только компетенциями мы не можем. С другой стороны, если компетенции не развивать, то будут оставаться ограничения в виде чемпионов, снижающие общую выработку.
Собственно, соотношение этих векторов и есть параметры стратегии. Тут важно что: вам не надо выбирать эти параметры раз и навсегда. Главное – вы понимаете, что они у вас теперь есть, эти рычажки и ползунки, регулирующие скорость и развитие, причем в цифрах.
Для начала можно выставить такие значения: 70 % – на задачи по развитым компетенциям, 30 % – на задачи по развитию. Понятно, что речь о сумме оценок задач. Хотя, можно и время в процентном соотношении делить. Даже, для простоты, выделить день в неделе на задачи по развитию.
Возникает соблазн подумать, что процент задач на развитие будет постепенно уменьшаться – разберутся же программисты, в конце концов, во всем, что необходимо? Нет, увы. Во-первых, платформа и решения развиваются. Во-вторых, люди приходят и уходят. Одного разовьете, он переедет в Москву, придется брать другого. Но вопрос «как его развивать» теперь не будет вас беспокоить – есть система с ползунком «скорость - развитие».
Понятно, что параметры стратегии зависят от того, кто вы – начальник, собственник, или программист. Собственнику и некоторым начальникам выгоден баланс развития и выработки, а также – система поддержания этого баланса. Начальнику выгоднее выработка. Программистам-чемпионам, скорее, выработка и немного развития. Обычным программистам, скорее, развитие.
Сам я – за баланс, потому что мне важнее выстроить саморазвивающуюся систему, чем получить сиюминутный результат. В нашем кейсе есть главное, что нужно для системы – учет и контроль развития компетенций, в цифрах.
Назначить дежурного
Сознательно избегаю использования слова «менеджер», потому что, повторюсь, не знаю вашей ситуации. Если вы – внутри команды, и начальник не с вами, то это будет именно дежурный, выбранный демократическим способом. Если вы – начальник, то решайте сами, будете дежурным вы или назначите кого-то из команды. Я рекомендую побыть дежурным самому.
Дежурный – это человек, который будет следить за выполнением правил и выполнять рутинную работу по администрированию системы. Часть обязанностей будет за программистами, но самая важная часть – регулярный менеджмент – будет в руках дежурного.
Дежурный будет, например, организовывать обсуждение входящего потока задач. Это не сложно, надо лишь встать и сказать что-то вроде «Так, все, бросаем работу, обсуждаем задачи. Давайте, их всего три на сегодня. Федя, хорош, потом покуришь. Колян, потом доделаешь. В смысле «лучше сейчас не отвлекаться»? Мы тебя ждать все будем? Блин, парни, договорились же, вы все башкой кивали, что в 9-00 у нас обсуждение задач. Давайте, не валандайтесь. Решили – надо делать, иначе нет смысла».
Дежурный отвечает за качество данных в системе – например, за правильное указание компетенций (и вообще за их указание). Дежурный управляет статусами задач. Так, я уже вперед забегаю, это материал следующей публикации.
Принцип вы поняли. Дежурный отвечает за то, что система работает. Не приносит результат, а именно работает, запущена, выполняется, как задумано. Это крайне важно, потому что, если никто не будет следить за выполнением правил, то они не будут выполняться. А если правила не будут выполняться, то результата не будет, выработка не удвоится, а скорее уменьшится, и вы через неделю бросите все это, так и не начав.
Через какое-то время выполнение правил войдет в привычку, и дежурить станет просто. В команде из 5 человек будет уходить минут 15 в день. По ходу придумаете, как автоматизировать часть контроля правил – вы же программисты.
Поговорить с программистами
Этот пункт – опциональный, необходимость в нем зависит от того, кто вы. Лично я рекомендую все-таки с программистами поговорить, объяснить перспективы и суть изменений. Обязательно дайте им почитать про комплект увольнения. Хорошо, если вам удастся программистов вдохновить. Если вы раньше устной мотивацией не занимались, то получите полезный опыт, особенно если делаете это не «в первый и последний раз».
Скорее всего, у вас не получится вдохновить их с первого раза, независимо от вашей роли. Программист 1С – особый человек, с сильно выраженной диалектикой в оценке своего места в мире. С одной стороны, он понимает, что приносит пользу этому миру. С другой стороны, он переживает, что он – не настоящий программист, получает большие деньги зря и, вообще, он – кто-то вроде «приживалы», подсевшего на временную, но прибыльную тему. Отчего программиста 1С не покидает ощущение, что все это когда-нибудь закончится.
Такая диалектика приводит к легкой форме профессиональной шизофрении, поэтому, убеждая в чем-то программиста, вам придется общаться с двумя личностями, сидящими в нем. Вектор такой: поддерживать и развивать позитивную часть и нейтрализовывать негативную. Собственно, все бизнес-программирование призвано, в том числе, лечить этот дуализм. Во-первых, помогая приносить больше пользы бизнесу, выходя за рамки автоматизации. Во-вторых, нейтрализуя риск «все это когда-нибудь закончится».
Если не получится вдохновить – не расстраивайтесь. Заранее решите, что у вас не получится убедить программистов, тогда и не расстроитесь. Они вдохновятся сами, когда увидят результат – рост выработки и, соответственно, доходов. Тогда станут вам помогать.
Как вариант, можно применить изоляцию – брать в эксперимент не всю команду, а только ее лояльную или нейтральную часть. Негативно настроенных чемпионов можно оставить в стороне, пусть работают, как работали. Важно не давить на них, не внедрять изменения «на спор», и не пытаться им что-то доказать.
Когда у вас получится, например, поднять доходы изолированных средних программистов до уровня чемпионов, этим самым чемпионам придется что-то решать. Если вы все время на них давили, или тыкали им в нос своими успехами, то они будут сопротивляться до последнего, или просто уйдут, чтобы сохранить чувство собственной важности.
Поэтому будьте предельно аккуратны и сдержаны в общении с чемпионами. Хотя, повторюсь, если чемпион – настоящий, то все эти придворные церемонии не нужны – он пойдет за изменениями в первых рядах. Псевдочемпионы, которым важнее сохранить роль и положение, будут сопротивляться.
Продолжение следует. По материалам https://business-programming.ru
