1С, не болей
Я в жизни видел два типа бизнеса, которые развиваются хуже всех — франчайзи 1С и продавцы елок. Речь не о развитии вширь, когда просто поголовье программистов растет, а о внутреннем развитии. Об эффективности, короче.
Хотя, наверное, продавцов ёлок можно исключить из этого списка, они сумели меня удивить перед Новым Годом, продав мне настоящую ель. Раньше только пихты и сосны бывали. Я даже в интернете посмотрел, как отличить ёлку от пихты — реально, это была ель.
Так что в списке «Самые неразвивающиеся компаниии» остаются только франчайзи 1С. Там работает куча прекрасных людей, но то ли среда такая, то ли место проклятое — с ними что-то не так.
Они думают только о сегодняшнем дне. Возможно, виновата жесткая привязка к одному вендору, который разрабатывает и фреймворк, и прикладные решения. Никто же в здравом уме не будет в 21 веке строить долгосрочный бизнес, завязанный на один язык программирования, одну среду разработки, один рынок? А вот ковать железо, пока горячо — пожалуйста. Когда остынет, тогда и можно будет задуматься о чем-то серьезном.
Но мне, почему-то, кажется, что не все потеряно. Можно сделать лучше.
Разные методы повышения эффективности — это, конечно, интересно. Но намного интереснее комбинация этих методов для конкретной деятельности — кейс. Он включает в себя процессы, мотивацию, автоматизацию, цели и систему управления. Не всегда все компоненты сразу — только то, что нужно.
Попробуем сформировать кейс для конкретной части знакомого нам бизнеса — 1С: Франчайзи. Знакомый он нам потому, что есть опыт работы в других франчах в течение нескольких лет, плюс — мы постоянно с франчами сталкиваемся, в формальной и неформальной обстановке.
Кейс будем формировать на основе совокупного опыта — почти все, что напишем, опробовали на себе. Никого ни в чем не убеждаем, интерес чисто академический. Хотя, нашлись крупные франчи, взявшие этот кейс на вооружение, и сами там чего-то внедряют.
Если вы не знаете, что такое 1С: Франчайзи, то читайте так, будто речь о некой компании, оказывающей услуги по разработке, сопровождению и доработкам ПО.
Цель кейса простая — повысить выработку программистов и, по возможности, выручку. Или выхлоп, у него разные варианты есть. Поехали. Предупреждаю — лонгрид.
Исходная ситуация
Возьмем не весь франч, а его часть, которую назовем отдел разработки. Это ребята, программисты 1С, которые сидят в офисе, получают задачи через систему или от консультантов, решают, сдают результат консультантам или клиенту, удаленно.
В крупных сетевых франчах таких отделов несколько, между ними бывает конкуренция, при этом они, когда не хватает ресурсов, активно обмениваются и специалистами, и задачами. Возможно, не по своей воле, но это не суть — мы смотрим на отдел разработки, как на бизнес-подразделение, а не как на сборище «настоящих программистов».
Допустим, наш отдел разработки состоит из пяти человек. Общая среднемесячная выработка составляет 500 часов. Из них 200 закрывает некий Чемпион — самый опытный и толковый кодер. 100 часов закрывает Второй, по 80 — Третий и Четвертый, 40 — Новичок.
Допустим, час работ для клиента стоит 2000 рублей. Допустим, у нас единая внутренняя ставка для программистов — 500 рублей в час. Простые подсчеты говорят, что выручка отдела — 1 млн. рублей в месяц, ФОТ отдела — это просто 25% от выручки, в данном случае — 250 тыс.рублей. Итого, компания получает 750 тыс. рублей, из которых платит налоги на тех же программистов, ну и все свои остальные расходы. Структуру прибыли рассматривать не будем, просто понимаем, что она нелинейная, т.к. содержит постоянные расходы, вроде аренды офиса и покупки печенек.
Выработка, допустим, относительно стабильная, сильно не прыгает. Разве что, когда Чемпион уходит в отпуск, имеем провал процентов на 40. Иногда случается и 700 часов — когда случился хороший проект, и программисты работают по выходным.
Цель кейса
Сразу цель применения кейса расскажу, чтобы не создавать таинственности. Мы хотим, чтобы наш отдел разработки выдавал не 500, а 1000 часов в месяц, т.е. вдвое больше. За ту же часовую ставку, с теми же постоянными затратами, с тем же количеством рабочих часов. Можем допустить небольшие временные расходы на этот проект — допустим, в пределах 30–50 т.р.
Тут важно сразу решить, что мы будем делать в целевой ситуации. С одной стороны, мы продаем время специалистов — часы, которые они тратят на решение задач. С другой стороны, мы продаем решенные задачи, оценивая их в часах. Вроде все понятно, но разница между этими двумя системами оценок довольно значительна.
Допустим, наши 500 часов в месяц — это 500 реальных часов работы специалистов. За эти 500 часов они решают, допустим, 200 задач, со средним ценником 2.5 часа. Получается, каждая задача в среднем стоит 5000 рублей. Клиент вполне готов платить такие деньги, он знает рынок, у остальных франчей цена такая же.
И вот мы научились решать задачу не за 2.5 часа, а за 1.25 часа. Ключевой вопрос — почём ее продать клиенту?
Если мы продаем время, то логично продать за 1.25 часа. Клиент будет чертовски доволен — и дешевле, и быстрее. Но нам, как бизнесу, от такой схемы выгоды почти нет — только довольный клиент и свободное время специалистов, которое надо чем-то занять. Допустим, мы нашли еще клиентов, и тоже продаем им задачу по 1.25 часа. В итоге, за месяц, что мы получим? Те же 500 часов по 2000 рублей. Смысла нет.
Один из вариантов — поднять часовую ставку. Мы же решаем задачи быстрее конкурентов? На мелких работах этого особо никто не заметит, а вот на задачах в 40 часов разница уже будет ощутимой.
Но цена часа — достаточно заметное для внешнего мира изменение, которое может отбить от нас новых клиентов. Они же не знают, что мы делаем вдвое быстрее? Лозунги, написанные на сайте, не особо убедительны.
Вроде правильнее продолжить продавать задачу за 2.5 часа. Клиент ничего не замечает, а у нас получается нормальный, целевой результат — делая вдвое больше задач, получаем вдвое больше денег.
Можно выбрать компромиссный вариант — продавать, например, за 2 часа. Тогда клиент видит ощутимую экономию (особенно на больших объемах), получает результат быстрее, и мы — в плюсе. Причем, даже с сохранением внутренней ставки программистов.
Для простоты будем рассматривать вариант, когда мы продолжаем продавать по 2.5 часа. Оценка входящей задачи у нас идет по чуть более сложному алгоритму — надо прикинуть реальное время, и умножить его на 2. Но об этом позже.
Да, есть еще экзотические варианты использования освободившегося времени, например — усиление внутренней разработки. Об этом будет в конце.
Ну все, цель понятна, теперь перейдем к анализу необходимых изменений.
Ключевая проблема
Говорят, всегда есть точка приложения силы, в которую надо вставить рычаг и получить максимальный эффект. Я с этим не согласен — в смысле, что такая точка есть всегда. Но в данном кейсе она есть — система мотивации.
Система мотивации у нас — индивидуальная, часовая ставка за выполненные работы.
Плюсов для программистов в ней много, для бизнеса — мало, а вот минусов — хоть отбавляй.
У специалиста полностью отсутствует причина делиться своими знаниями и опытом. Единственное, ради чего это стоит делать — чтобы поднять свою важность. Если с важностью все в порядке, то делиться опытом, а тем более помогать в решении задач — противопоказано. Научишь дурака — он станет твоим конкурентом, а тебе даже спасибо не скажет.
Если ты хорошо знаешь, например, зарплату (это программа такая), а другие не знают — у тебя всегда будет хлеб с маслом. Как только появится второй зарплатник — тебе придется прикладывать усилия, чтобы получать наиболее лакомые участки работ.
Что в этом для бизнеса? Если специалисты не делятся компетенциями, то забота об обучении ложится на плечи компании. Надо организовывать курсы, либо платить сторонним организациям (вроде 1С). Второе — узкие места в виде ключевых специалистов. Если из 5 человек только один знает ERP (это тоже программа такая), то вы физически не можете брать работ по ERP больше, чем этот сотрудник способен переварить. Даже если это Чемпион, будет не более 200 часов в месяц. Ну либо рисковать — работы брать, чтобы разобраться потом, по ходу.
Заставить делиться компетенциями не очень возможно. Видимость сделать — можно. Но, кто был программистом, знает — есть способы оказывать помощь так, чтобы к тебе за ней больше не обращались. Можно заставить Чемпиона даже семинар, или обучение провести. Он честно отчитает материал — тот, который итак доступен в интернете. Реальные, практические знания он все равно оставит при себе.
Индивидуальная часовая ставка — это как бизнес внутри бизнеса, причем этот «внутренний бизнес» — всегда ИП, а не ООО.
А компетенции важны, особенно в эпохи перемен, которые периодически случаются. Бывает, конечно, затишье в пару лет — например, перед выходом ERP, когда уже все разобрались в УПП (это тоже программа, старенькая, но бодрая). Но в 2004 — 2010 годах, например, лучше всех жили «проектники», которые владели знаниями по УПП. Сейчас, наверное, знатоки ERP лучше всех живут — точно не знаю.
Индивидуальная сдельная оплата убивает возможность делиться рабочими решениями и наработками, потому что в этом, опять же, нет никакого смысла. Ну отдал ты человеку свою обработку или подсистему, он закрыл за день оговоренные с клиентом 40 часов, поднял 20 т.р. Тебе что с этого? Можно, конечно, договориться, и породить черный рынок внутри отдела, но смысла нет. Проще сказать «отдай мне задачу, я решу». В безвыходной ситуации, конечно, отдаст, но скорее — оставит себе, из принципа.
Можно посмотреть на компетенции иначе: кто их владелец? Допустим, ваш Чемпион работает в компании с 2010 года. Выполнил много работ по ERP, получил компетенции. Кому они принадлежат?
Компания скажет — нам принадлежат. Наши клиенты, наши проекты, наши задачи. Отдай компетенции. А как их забрать? Не клещами же тянуть? Это не материальный актив. Психанёт, уйдет, и плакали компетенции.
А что есть компетенции? Продукт. Или нет — доход от продажи продукта. Отгрузили 200 часов по ERP, получили два профита — 400 т.р. и компетенции. Деньги — понятно, вот они, на расчетном счете. Можно перевести, потратить, вложить. А компетенции где? Вон в той лысой башке. Что с ними можно сделать? По факту — ничего.
Получается, парень научился за наш счет. Не то, чтобы мы в его обучение деньги вкладывали — нет, просто так получилось. Но получить этот профит мы можем только одним способом — продолжать эти компетенции эксплуатировать, т.е. на все работы по ERP ставить его одного. Ну или рисковать и ставить новичка, чтобы получить очередной неизвлекаемый ресурс.
Причина такого положения дел банальна — неправильная система мотивации. Она не то чтобы не поощряет — прямо запрещает человеку делиться компетенциями.
Система мотивации — она ведь для чего нужна? Чтобы человек сам, по своей воле, и со всем усердием делал то, что выгодно компании. Система мотивации должна заменять руководителя, который каждый день ходит, пинает и пытается чего-то указывать.
Как сделать так, чтобы человек сам, по своей воле, делал то, что выгодно компании? Ну, во-первых, конечно, понять, что выгодно компании. Во-вторых, сделать так, чтобы выгода компании была выгодна человеку. Не в виде миссий и лозунгов, а по-настоящему.
Кейс
Для кейса я выбрал методы, которые, по моему разумению и опыту, наиболее подходят для достижения цели — удвоения выработки. Вообще, методов намного больше, но мы тут не писаниной занимаемся, а делом. Также, стоит отметить, что для удвоения выработки не обязательно внедрять все методы — зачастую достаточно какого-то одного.
Разница в начальных условиях конкретной компании, о которых я ничего не знаю. Наверное, есть на свете самый дебильный франч, у которого самая низкая выработка на сотрудника. Вы — не из этого франча, поэтому ваша метрика выше. А вот насколько выше — понятия не имею. Но то, что выработку у вас можно удвоить — факт.
Итак, что нужно сделать:
- Выбрать, автоматизировать и внести начальные остатки в систему оценок;
- Автоматизировать и внести начальные остатки в систему компетенций;
- Принять решение по системе мотивации, автоматизировать;
- Выбрать параметры стратегии компетенций;
- Назначить дежурного;
- Поговорить с программистами.
Делать:
- Общее обсуждение входящих задач;
- Выбор исполнителя по компетенциям в соответствии со стратегией;
- Управление взаимопомощью и ее учет;
- Управление статусами задач.
Теперь кратко изложу каждый пункт. Но сначала — пояснения по автоматизации.
Автоматизация
Пункт, который присутствует почти во всех вариациях кейса — автоматизация. Все изменения, которые вы будете вносить в процессы, управление и мотивацию, нужно быстро автоматизировать.
«Быстро автоматизировать» — это реально быстро, т.е. в течение дня (включая ожидание возможности обновить конфигурацию базы данных). Отсюда сразу вырисовывается необходимость выполнять эту автоматизацию силами той же команды, выработку которой вы увеличиваете. Если вы — большой франч, и внутренней автоматизацией у вас занимается другой, не подвластный вам отдел, то вам не очень повезло, но выход есть — тайная автоматизация.
Для всего, что есть в кейсе, хватит изготовленной на коленке самописанной конфигурации. Потом, когда-нибудь, вы ее улучшите, встроите в вашу корпоративную систему, сделаете эргономичный интерфейс и т.д. Сейчас нужны практически голые данные, без красивостей и удобностей. Поэтому, если у вас нет доступа к доработке общей системы, сделайте свою и расшарьте внутри команды.
Если у вас система управления задачами не на 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.
Теперь же будет по-другому. Исполнитель подходит к «знающему», предлагает сотрудничество. «Знающий» говорит — там делов на пару часов, у меня и пример есть, надо немного доточить, и все. Сколько хочешь? — спрашивает исполнитель. Ну, давай 40% — говорит «знающий». Исполнитель соглашается, за 15 минут получает наводку и ликбез, а заодно и примеры кода, решает задачу за 2 часа, получает 500 р. х 2 ч. х 60% = 600 рублей, т.е. на этом отрезке лично для себя он сработал по 266 рублей в час (600 рублей за 2.25 часа). Если бы делал сам, сработал бы по 100 рублей в час (потратил бы 10 часов, получил бы 1000 рублей).
«Знающий» сработал по 1600 рублей в час (потратил 15 минут, получил 400 рублей). Ну, на то он и знающий. Обычные работы, т.е. свой труд и свое время, он продает по 500 рублей в час, а свои реальные знания — по 1600 рублей в час. Никто не в минусе, большинство — в плюсе. Клиент получил решение быстро, ничего не потеряв в деньгах. Компания ничего не потеряла в деньгах, получила двух довольных сотрудников и довольного клиента. Исполнитель рад до ушей, а знающий, наконец-то, начал получать дивиденды от своих инвестиций в самообразование.
Понятно, что все пропорции будут варьироваться. Иногда знающему понадобится час на объяснение, а иногда — одна минута. Исполнитель тоже, когда за 2 часа сделает, когда 5 все-таки протупит. Но, тем не менее, средний выхлоп будет положительным, и весьма значительным.
Главное, на мой взгляд — полностью отдать распределение процентов программистам, и не вмешиваться в него. Пусть сами договариваются, они ведь взрослые люди.
Второе главное: если вы — начальник, то не пытайтесь забирать вот эти «халявные» часы у чемпионов. Есть ведь такой соблазн — заплатить только исполнителю, да еще и с понижающим коэффициентом за тупость. Мы в начале публикации договорились, что процент ФОТ не меняется — ни в плюс, ни в минус. При сохранении процента и удвоении выработки компания и так получит своё.
Стратегия по компетенциям
Раз у вас будет система реального учета компетенций, надо решить, как ей пользоваться. Принципиально вектора два — раздавать задачи тому, кто умеет их делать, и тому, кто не умеет.
Первый вектор дает максимальную скорость решения, но не дает развития компетенций. Второй вектор дает минимальную скорость решения, но максимальный рост компетенций.
Понятно, что лучший путь — где-то между векторами. С одной стороны, у нас бизнес, а не университет, и заниматься только компетенциями мы не можем. С другой стороны, если компетенции не развивать, то будут оставаться ограничения в виде чемпионов, снижающие общую выработку.
Собственно, соотношение этих векторов и есть параметры стратегии. Тут важно что: вам не надо выбирать эти параметры раз и навсегда. Главное — вы понимаете, что они у вас теперь есть, эти рычажки и ползунки, регулирующие скорость и развитие, причем в цифрах.
Для начала можно выставить такие значения: 70% — на задачи по развитым компетенциям, 30% — на задачи по новым областям знаний. Понятно, что речь о сумме оценок задач. Хотя, можно и время в процентном соотношении делить. Даже, для простоты, выделить день в неделе на задачи по развитию.
Возникает соблазн подумать, что процент задач на развитие будет постепенно уменьшаться — разберутся же программисты, в конце концов, во всем, что необходимо? Нет, увы. Во-первых, платформа и решения развиваются. Во-вторых, люди приходят и уходят. Одного разовьете, он переедет в Москву, придется брать другого. Но вопрос «как его развивать» теперь не будет вас беспокоить — есть система с ползунком «скорость — развитие».
Понятно, что параметры стратегии зависят от того, кто вы — начальник, собственник, или программист. Собственнику и некоторым начальникам выгоден баланс развития и выработки, а также — система поддержания этого баланса. Начальнику выгоднее выработка. Программистам-чемпионам, скорее, выработка и немного развития. Обычным программистам, скорее, развитие.
Сам я — за баланс, потому что мне важнее выстроить саморазвивающуюся систему, чем получить сиюминутный результат. В нашем кейсе есть главное, что нужно для системы — учет и контроль развития компетенций, в цифрах.
Назначить дежурного
Сознательно избегаю использования слова «менеджер», потому что, повторюсь, не знаю вашей ситуации. Если вы — внутри команды, и начальник не с вами, то это будет именно дежурный, выбранный демократическим способом. Если вы — начальник, то решайте сами, будете дежурным вы или назначите кого-то из команды. Я рекомендую побыть дежурным самому.
Дежурный — это человек, который будет следить за выполнением правил и выполнять рутинную работу по администрированию системы. Часть обязанностей будет за программистами, но самая важная часть — регулярный менеджмент — будет в руках дежурного.
Дежурный будет, например, организовывать обсуждение входящего потока задач. Это не сложно, надо лишь встать и сказать что-то вроде «Так, все, бросаем работу, обсуждаем задачи. Давайте, их всего три на сегодня. Федя, хорош, потом покуришь. Колян, потом доделаешь. В смысле «лучше сейчас не отвлекаться»? Мы тебя ждать все будем? Блин, парни, договорились же, вы все башкой кивали, что в 9–00 у нас обсуждение задач. Давайте, не валандайтесь. Решили — надо делать, иначе нет смысла».
Дежурный отвечает за качество данных в системе — например, за правильное указание компетенций (и вообще за их указание). Дежурный управляет статусами задач.
Принцип вы поняли. Дежурный отвечает за то, что система работает. Не приносит результат, а именно работает, запущена, выполняется, как задумано. Это крайне важно, потому что, если никто не будет следить за выполнением правил, то они не будут выполняться. А если правила не будут выполняться, то результата не будет, выработка не удвоится, а скорее уменьшится, и вы через неделю бросите все это, так и не начав.
Через какое-то время выполнение правил войдет в привычку, и дежурить станет просто. В команде из 5 человек будет уходить минут 15 в день. По ходу придумаете, как автоматизировать часть контроля правил — вы же программисты.
Поговорить с программистами
Этот пункт — опциональный, необходимость в нем зависит от того, кто вы. Лично я рекомендую все-таки с программистами поговорить, объяснить перспективы и суть изменений. Обязательно дайте им почитать про комплект увольнения. Хорошо, если вам удастся программистов вдохновить. Если вы раньше устной мотивацией не занимались, то получите полезный опыт, особенно если делаете это не «в первый и последний раз».
Скорее всего, у вас не получится вдохновить их с первого раза, независимо от вашей роли. Программист 1С — особый человек, с сильно выраженной диалектикой в оценке своего места в мире. С одной стороны, он понимает, что приносит пользу этому миру. С другой стороны, он переживает, что он — не настоящий программист, получает большие деньги зря и, вообще, он — кто-то вроде «приживалы», подсевшего на временную, но прибыльную тему. Отчего программиста 1С не покидает ощущение, что все это когда-нибудь закончится.
Такая диалектика приводит к легкой форме профессиональной шизофрении, поэтому, убеждая в чем-то программиста, вам придется общаться с двумя личностями, сидящими в нем. Вектор такой: поддерживать и развивать позитивную часть и нейтрализовывать негативную.
Если не получится вдохновить — не расстраивайтесь. Заранее решите, что у вас не получится убедить программистов, тогда и не расстроитесь. Они вдохновятся сами, когда увидят результат — рост выработки и, соответственно, доходов. Тогда станут вам помогать.
Как вариант, можно применить изоляцию — брать в эксперимент не всю команду, а только ее лояльную или нейтральную часть. Негативно настроенных чемпионов можно оставить в стороне, пусть работают, как работали. Важно не давить на них, не внедрять изменения «на спор», и не пытаться им что-то доказать.
Когда у вас получится, например, поднять доходы изолированных средних программистов до уровня чемпионов, этим самым чемпионам придется что-то решать. Если вы все время на них давили, или тыкали им в нос своими успехами, то они будут сопротивляться до последнего, или просто уйдут, чтобы сохранить чувство собственной важности.
Поэтому будьте предельно аккуратны и сдержаны в общении с чемпионами. Хотя, повторюсь, если чемпион — настоящий, то все эти придворные церемонии не нужны — он пойдет за изменениями в первых рядах. Псевдочемпионы, которым важнее сохранить роль и положение, будут сопротивляться.
Главный принцип
Многие задаются вопросом — как такое вообще возможно, что выработка вырастет вдвое? За счет чего? Мы что, код сможем быстрее писать? Или снизим его качество? Тяп-ляп и в продакшн? Многие, конечно, не задаются, а просто отрицают и отвергают. Ведь невозможно, чтобы была где-то проверенная методика двукратного ускорения, а никто о ней не знал?
Проблема, на самом деле, банальная — неправильный вектор внимания. Или, проще говоря, вы не туда смотрите. Сузим тему до программистов, хотя принцип универсален.
Какова, по-вашему, идеальная скорость решения задачи клиента программистом 1С? Речь о задаче на разработку или доработку. Подумайте, пока читаете, ответ будет чуть ниже.
Давайте присмотримся к работе программиста 1С. Как думаете, сколько процентов времени он, собственно, программирует (включая все аспекты — написание кода, создание метаданных, макетов и т.д.)? 100%? 50%? 20%?
Практика показывает, что бывает и 3%. Если не верите, проверьте на себе — есть специализированные программы для таких измерений. Но есть способ проще — посмотрите на объем кода, написанный программистом за день, и разделите на его скорость печати. Получившаяся цифра может вас удивить.
Разум программиста возмутится — ну как же, причем тут вообще объем кода и скорость печати? Есть задачи, где надо тупо и много писать. А есть такие, где надо много читать, думать, анализировать и пробовать, долго отлаживать.
Ок, зайдем с другой стороны. Весь день программист думал, анализировал, пробовал. В итоге написал 50 строк кода, и задача решена. Хороший, правильный код, все проверено и работает. Потратил 8 часов.
Теперь вопрос: за какое время он решит точно такую же задачу от другого клиента? Если просто возьмет готовое решение, то минут 5, верно? Ну, пока там конфигуратор откроется, пока второй, пока скопирует и т.д. А если заново написать, ручками? Полчаса? По дороге еще и ревью сделает, на автомате, и код улучшит. В 16 раз быстрее.
Ладно, черт с ним, с копированием кода. Другой пример. Вы, вместо того, чтобы дать программисту одну задачу, дали 10–20 — сказали: вот трекер, выбирай любую и делай. Что будет дальше?
Программист будет выбирать. В программном коде оператор выбора срабатывает за долю миллисекунды (если не очень сложное условие), но человек-то — не машина. Для него выбор — это процесс, который порой идет оооооочень медленно.
Иногда такой про
