Я в жизни видел два типа бизнеса, которые развиваются хуже всех — франчайзи 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 – сказали: вот трекер, выбирай любую и делай. Что будет дальше?
Программист будет выбирать. В программном коде оператор выбора срабатывает за долю миллисекунды (если не очень сложное условие), но человек-то – не машина. Для него выбор – это процесс, который порой идет оооооочень медленно.
Иногда такой процесс напоминает разведку боем: программист не только читает заголовок задачи и детальное описание, но и комментарии, а потом – лезет в конфигуратор, чтобы понять контекст. Посмотрит, потыкается – фу, скажет, это задача про спецодежду, там черт ногу сломит, в этой УПП. Не, пусть Колян делает. Минут 15 потеряно. Умножаем на 10-20, сколько получится? До 5 часов?
Это ладно, если программист толковый, и ему достаточно контекста для принятия решения. А он, допустим, большой любитель интернета, и пошел искать готовое решение – на том же Инфостарте, или партнерской конференции, или еще где. Время выбора начинает расти с устрашающей скоростью.
Полдня будет выбирать, полдня будет работать. Потери – 50%, т.е. кому-то достаточно правильно выдавать задачу, чтобы повысить выработку вдвое.
Ладно, нет у нас такой проблемы, как выбор. Выбирает менеджер, или главный программист, и говорит – вот, эту делай. Нет, не хочу, не могу, пусть лучше Колян делает – отвечает программист. Делай, я сказал! – настаивает главный.
Дальше, по разумению главного, программист сел и делает. Пусть не очень эффективно, но делает. А что он делает? Иногда – да, решает задачу. Иногда – сидит и обижается. Или ищет причины не делать задачу. Например, готовит перечень вопросов, «без решения которых начинать бессмысленно». Или в интернет тупит, потому что мир не справедлив.
Примеры закончу, хотя их, на самом деле, десятки. Получается, есть два состояния у программиста – пишет код или тупит. Слово «тупит» использовано без негативной коннотации, просто не нашел более подходящего глагола от существительного «ступор».
Вот и главный принцип нарисовался: смотри туда, где тупит. Нет особого смысла начинать рост эффективности с процесса написания кода, выбора другой среды разработки (типа EDT), всяких приблуд для ускорения кодирования и т.д. Считайте, что когда программист пишет код – он эффективен. Вот прям когда пальцами на клавиатуре стучит, или мышкой формы рисует и реквизиты добавляет.
Основное время теряется там, где программист тупит, а не там, где он пишет код. Несколько вариантов я рассказал.
Если вы – руководитель программистов, перестаньте смотреть на написание кода, посмотрите на простои. Если вы – программист – посмотрите на себя, на свои простои. Это – ключ к повышению скорости разработки.
Возвращаемся к вопросу – каково идеальное время решения задачи клиента программистом 1С? Ответ очевиден – ноль. Ну ладно, совсем ноль не бывает, пусть будет 5 минут. Как достигается такое время? Вы уже понимаете: выдачей готового решения. Пришел клиент, сказал свою задачу, а вы ему сразу – решение, которое у вас уже есть. Сколько взять денег – не знаю, ну не за 5 минут работы специалиста, это точно. Можно спорить с этим утверждением, а можно задуматься. Сколько раз вы решали идентичные задачи? Каков процент задач, которые вы решаете в первый раз, и вообще о подобном не слышали? У меня практика небольшая – всего 13 лет, но даже с такой скромной цифрой я понимаю и вижу, что половину задач я уже решал.
Если вооружиться таким подходом, то потребуется совсем немного – писать абстрактные настраиваемые инструменты (вместо контекстного, сиюминутного говнокода) и где-то их хранить. Первое мы обсуждали, второе имеет массу вариантов решения.
Тут я немного вышел за рамки кейса. Я не призываю вас все бросить и заниматься готовыми решениями, просто хотел показать идеал – ускорение уже, по сути, не разработки, а продажи в десятки и сотни раз. Соответственно, и ускорение генерации дохода франча в сотни раз. Пока займемся чем помельче – вдвое ускоримся.
Принцип вы поняли, дальше вам будет все понятно и просто. Я опишу действия, которые надо включить в процесс работы отдела, с одной целью – уменьшить время тупежа, заместив его программированием.
Просто и банально. Дежурный, которого мы обсуждали в прошлой статье, каждое утро собирает всех программистов в кучу, и они дружно смотрят на новые задачи.
Первое, что надо выяснить – решал ли кто-то подобную задачу. Если решал, то назначить его консультантом, или куратором – не важно, как назвать. Важно, чтобы исполнитель знал, к кому обратиться.
Если такого никто не делал, то немного упрощаем критерии – ищем тех, кто работал с этой подсистемой, или этим документом, или этим механизмом платформы. Ну, понимаете – если задача про рисование Планировщика, то сойдет любой, кто уже смог осилить этот невероятный механизм. Он и будет консультантом.
Если задача вообще новая, и никому не знакома даже близко, то надо выбрать раскуривателя – того, кто будет в этой теме разбираться первым. Ключевых задачи две: решить задачу и наработать компетенцию. Чтобы в следующий раз стать консультантом по подобным задачам. Разумеется, всем понятно, что на раскуривание может уйти больше времени, чем согласовано с клиентом – это нормально, вы инвестируете в свою команду.
Наличие консультанта особенно важно для новичков. Даже если вы, по своей стратегии развития компетенций, запретите новичку спрашивать куратора, сам факт его наличия будет оказывать новичку колоссальную моральную поддержку.
Ну и не забудем дать оценку задаче, в баллах – сыграть в покер планирования.
Тут все просто. Вы сделали выбор – отрегулировали ползунок между выработкой и повышением компетенций. Вот и выбирайте исполнителя в соответствии со своей стратегией.
Например, вы решили, что новички должны решать незнакомые задачи 30 % времени. В системе у вас уже есть отчет, который показывает процентное соотношение – сколько знакомых, сколько незнакомых задач он решал. Смотрите на цифры и решайте, в какой момент выдать новую, незнакомую задачу.
Наличие консультанта снимет избыточный потенциал важности с задачи, и придаст процессу элементы игры. Новичку будет интересно разобраться с новыми механизмами, потому что он будет знать о наличии поддержки, чувствовать ее. Если вы заранее оговорите границы применения этой поддержки, будет вообще замечательно: например, дадите новичку на самостоятельную работу не более одного дня, после чего решением займется консультант.
Степень и формат поддержки от консультанта выбирайте сами, тут ничего сложного. Если новичок – совсем новый, то нет смысла давать ему ссылку на партнерскую конференцию, толстую книгу по разработке и подбадривать «давай, разбирайся, сынок». Такой большой кусок он просто не сможет переварить, подавится, и вы можете потерять сотрудника. Он не уволится, но получит существенный удар по своей значимости, может стать закрытым и инертным.
Однозначных советов по выбору «размера куска» нет, потому что все строго индивидуально. Универсален один принцип: за этим размером нужно следить. Разумеется, если вы хотите эффективность повысить, а не собственную значимость. Такой способ самовыражения, как постановка нерешаемых задач, в среде программистов 1С слишком широко применяется, чтобы не говорить о нем.
Есть и исключения – сотрудники, которые хотят во всем разобраться самостоятельно. Настолько хотят, что наотрез отказываются от любой помощи. Это их способ повышения значимости – «я могу разобраться сам», и чем шире контекст, в который он вникнет, тем больше награда – самоудовлетворение. Это полезное качество, но оно иногда в манию переходит – лучше за таким следить, ставя границы (по времени, например).
Если задача срочная, или клиент для вас важен, то эксперименты выключаются, и на задачу садится тот, кто лучше всех разбирается. Ну, это всем понятно.
Раз есть консультант, неплохо бы его замотивировать – дать процент от почасовой оплаты за решение задачи. Размер процента зависит от степени участия.
Разумеется, надо сделать так, чтобы консультант не наглел, и не тянул одеяло на себя, когда задача назначена новичку. Не забываем, что наша цель – не сиюминутная выгода, а долгосрочный успех.
Ну и за новичком надо следить. Если вы решили, что он в данной задаче познает только работу с Планировщиком, не позволяйте ему брать на себя весь остальной контекст задачи – пусть его расскажет консультант.
Собственно, тут больше нечего добавить.
По этой теме была отдельная статья, все повторять не буду. Статья, кстати, не особо заинтересовала 1Сников, но пришлась по вкусу представителям других рас разработчиков – мы с ними активно работаем теперь. Это я к тому, что в мире программирования 1С пока не все хорошо с методами повышения эффективности.
Когда выберете дежурного, дайте ему ссылку на статью, приведенную выше. Главное, что он должен понять, принять и исполнять – за статусами задач нужно следить.
Каждое его утро должно начинаться с ритуала – управления статусами задач. Это очень просто и легко автоматизируется. В первом окне – новые задачи, еще не принятые в работу. Это – список для обсуждения с командой, которое мы рассмотрели выше. Итогом обсуждения должно стать опустошение этого окна.
Во втором окне – задачи, принятые в работу, но не имеющие исполнителя. Опустошается так же, после общего обсуждения. По итогам обсуждения оба списка должны стать пустыми. Допустимое время нахождения задачи в статусах «Не принято в работу» и «Не назначен исполнитель» — не более одного рабочего дня.
Если задача не понятна, и требуется уточнение заказчика – задача, вместе со списком вопросов, переезжает в окно/статус «Требуется уточнение» или «Отправлено на доработку» — не важно, как назвать. Важна детерминированность.
После обсуждения (или перед ним) дежурный проверяет список отправленных на доработку, чтобы не было просрочки статусов. Например, на уточнение постановки отводится три дня. Прошло три дня – надо написать заказчику, чтобы не тормозил. Он, с высокой вероятностью, просто забыл ответить.
Во время обсуждения с программистами смотрим на окно «В работе». Оно у нас ранжированное: все понимают, кто какой задачей занимается. Соответственно, есть время нахождения задачи в статусе «В работе», с привязкой к исполнителю, и это время надо контролировать.
Банально – для того, чтобы не пропустить границу времени познания для новичка. Если ему дали сутки на самостоятельное решение, и эти сутки прошли, то он, с высокой вероятностью, не поднимет руку и не скажет, что не справился. Будет тупить до последнего. Нам это не надо, поэтому банальный контроль за временем жизни статуса спасет от лишних потерь, а новичка – от чувства вины за свою тупость.
Последнее окно – выполненные задачи, требующие акцепта от заказчика. Тут принцип такой же, как в отправленных на доработку – ставим срок, например, три дня, после которого начинаем напоминать о себе. Спокойно, уверенно, но настойчиво. Повторю, заказчик мог просто забыть, у него своих дел хватает.
Ну все, заканчиваем кейс. Главная цифра, о которой шла речь – внутренняя стоимость единицы работ, т.е. балла. Я утверждал, что можно эту стоимость снизить вдвое – производить то же количество работ за вдвое меньшее время.
Вот наш график, по одному из клиентов (ключевому на данный момент):
Как видите, до применения кейса (т.е. до апреля) стоимость балла болталась примерно на одном уровне. Это означает, что, тратя одно и то же количество часов, мы производили одно и то же количество результата – в среднем 1 балл за 0.9 часа.
В первый месяц применения кейса стоимость балла резко упала, до 0.22 часов, это примерно в четыре раза. Первый месяц, конечно, стоит учитывать, но ему нельзя доверять полностью, потому что там был резкий скачок сдачи работ – закрылось несколько «дорогих» задач, которые из-за неуправляемого жизненного цикла задач тянулись, как резина.
Второй месяц – более показательный и правильный. Во-первых, уже не было старых задач, которые бы закрылись – все задачи, закрытые в мае, родились в предыдущие два месяца, т.е. во время применения кейса. Во-вторых, применение кейса устаканилось и вошло в привычку. Итог – 0.33 часа за 1 балл, что в три раза лучше, чем было до кейса.
Ну а дальше цифра стала болтаться в районе обещанного среднего — половины от исходного.
Разумеется, положительные результаты получились не только по этому клиенту, но и в целом по всем работам. В том числе – по внутренним, которых у нас достаточно много – больше, чем для внешних клиентов.
Вот, например, график суммарного количества произведенных баллов:
Как видите, до кейса мы в среднем выдавали 400-500 баллов в месяц, а потом эта цифра выросла до 1400 – прирост в 3 раза.
Оба графика обрезаны октябрем, увы — мы раньше вели задачи в гитхабе, а потом переехали в Flowcon. Общий график, из двух источников, рисовать лень.
Здесь интересно понять зависимость цифр. Мы, Окнософт, стараемся мало заниматься услугами для клиентов, наш приоритет – разработка. До применения кейса у нас была проблема – на клиентов уходило слишком много времени, а на разработку оставалось очень мало.
Применение кейса позволило нам из этой ловушки выбраться – у нас появилось, пусть еще недостаточно, но намного больше времени на развитие. Результат не заставил себя ждать: мы реализовали несколько очень важных для нас продуктов.
Первый – сайт нашего проекта по бизнес-программированию (ссылку не буду давать, а то опять получу письмо с темой «nmivan, пройдемте...»). Ключевое слово — сайт, потому что раньше мы делали только бизнес-приложения, работающие через интернет. Сайт сделан на платформе metadata.js, но ключевым успехом является не сам сайт, и не контент, а доработка платформы и ее компонентов. Теперь на metadata.js можно делать еще и сайты. Причем, сайт содержит функциональность CMS и микросервисы.
Второй проект, до которого долго не доходили руки – безбумажка, т.е. функциональность цеховой диспетчеризации, работающая через браузер и с крутой визуализацией (это важно для оконного производства, например). Работа безбумажки через браузер – например, использование сканера штрихкодов, подключенного к телевизору – значительно расширит и упростит возможности применения решений на metadata.js в производстве. Особенно с учетом простоты работы с внешними событиями в коде metadata.js – их можно ловить в любом месте, а не только в активной форме, как в 1С.
Про третий проект рассказывал — Flowcon.Life. Для нас он крайне важен, т.к. дал кучу полезных задач по развитию платформы. Это первый проект для людей, а не для бизнеса.
Четвертый вам вряд ли интересен — это Flowcon, конфигурация для 1С + сервис управления задачами/командой/бизнесом.
Ну и еще несколько — либо поменьше и поскучнее, либо побольше и посекретнее. Итого, допустим, шесть штук.
Много это или мало? Уточню — для двух человек. Которые еще и с клиентами работают на проектах внедрения, статьи пишут, много ругаются друг с другом и со всем миром, да еще и ленивые до чертиков.
Все познается в сравнении. Шесть проектов за 9 месяцев – много или мало? Если вспомнить, что за предыдущие 6 месяцев проект был один (сервис параметрических заказов), то прирост значительный – с 0.15 проекта в месяц до 0.66 проектов в месяц.
Для нас эти проекты ценнее, чем отгруженные часы, потому что они нас развивают — все, что мы вкладываем в понятие Окнософт. Платформу, продуктовую линейку, каналы продаж, функциональность тиражных решений. В отличие от отгруженных часов, единственный выхлоп которых – деньги.
Конечно, проекты все разные по сложности и трудозатратам, и только по их количеству судить сложно. Поэтому мы и используем несколько цифр, которые я привел, чтобы понимать свое состояние и динамику максимально адекватно.
Видя комплексную оценку, мы понимаем, что кейс работает и приносит реальную пользу бизнесу, причем – очень быстро. В нашем случае этого кейса мало, потому что, как вы поняли, наш приоритет – разработка.
Кстати, это и есть тот самый экзотический сценарий использования ускорения. Мы вот не стали больше услуг продавать клиентам, а потратили освободившееся время на новые продукты. Не знаю, правы мы или нет, время покажет — может, и правда надо думать только о сегодняшнем дне? Как большинство франчей делают.
Ну, про нас поговорили, теперь про вас. Я уверен, что у вас при чтении статьи возникли вопросы. Тема ускорения для меня не новая, поэтому часть вопросов, которые вы захотите задать, я много раз слышал, и отвечу на них сразу. Вопросы сгруппирую.
Вера не требуется. Если вы считаете, что вам нужна вера, то с вами что-то не так.
Вера была бы нужна, если бы я вам чего-то продать пытался – консалтинг, книжку, семинар или членство в клубе. Тогда и у меня был бы мотив вашу веру взращивать. Но я вам ничего не продаю, поэтому вопрос веры – сугубо ваш личный, он субъективен и никак со мной не связан.
Ну и вообще, у нас тут кейс, а не секта. У нас – бизнес, у вас – тоже. Наш бизнес вашему ничего не должен, как и ваш – нашему. Причем, верить тоже не должен.
Вот когда один программист 1С придумал, как ускорить проведение документов вдвое, и изложил этот способ, нужна ли второму программисту 1С вера, чтобы попробовать применить тот же способ? Не исключаю, конечно, что кому-то нужна, но большинству – нет.
Ставишь копию базы, вносишь предложенные изменения, смотришь на результат. Получилось вдвое – круто. Получилось в 1.5 раза – круто. Не изменилось или стало хуже – пишешь автору. Он или попробует помочь, и сделает свой способ более абстрактным, или скажет «пф, мне-то что, у меня получилось».
Что плохого случится со вторым программистом 1С? Ничего. Даже если результата не будет, он просто потратит немного времени – причем, с пользой.
С кейсом ситуация ровно та же. Как я говорил в первой статье, затраты на его внедрение – ничтожны. Большинство методов вообще внедряются бесплатно. Покупать ничего не требуется, в том числе у нас.
Зачем тогда вера?
Что смог – показал. Про «доказать» — см. выше, про веру, смысл один и тот же.
Доказательство – это очень трудоемкий процесс, и цель его – собственно, доказательство. У меня такой цели нет, я же не диссертацию защищаю. Доказать вы можете сами себе, если попробуете. Я вам ничего доказать не смогу.
Даже не смогу доказать, что у нас кейс сработал. Элементарно – вы скажете, что я графики от балды нарисовал. И какие бы цифры, отчеты, выписки со счета или из налоговой я не привел, вы сможете сказать – «пф, а причем тут кейс вообще?».
Понимаете? Доказательство, вера и т.д. – это ваше личное, внутреннее, не имеющее ко мне никакого отношения. Это стереотип такой, внутреннее убеждение, особенность восприятия, а скорее всего – способ самозащиты: не буду ничего менять и делать, пока мне не дадут веру и не докажут. Звучит понятно и правильно, но полностью обрубает возможность изменений, по одной простой причине – никто не собирается вам ничего доказывать.
Если не пробовать – да, не получится. Тоже способ самозащиты. Непонятно только, от кого.
Вот это самое забавное, на мой взгляд. Кого вы пытаетесь убедить, что это не работает? Меня? Так у меня работает.
Если бы я писал кейс о том, как «можно было бы поработать», то смысл в таких утверждениях был бы – предупредить меня о том, что я занимаюсь ерундой.
Если вы пытаетесь убедить остальных читателей, то ваши цели мне не понятны. Не буду оспаривать их важность и ценность, просто не понимаю. Вам какое дело до остальных?
Если пытаетесь убедить себя, то у вас отлично получается.
«У нас совсем другая проблема – вот такая и вот такая»
Прекрасные и очень полезные комментарии. Я обязательно учту их в своей работе – мне важно знать о том, что вас беспокоит и в чем есть проблемы.
Что надо делать автору – не имеет никакого значения. За ссылки и наводки, разумеется, спасибо.
Если убрать противопоставление, то – отличный комментарий. Решать надо все проблемы, так или иначе. Вопрос в приоритетах, а они – субъективны для каждого бизнеса и человека.
Кейс направлен на решение конкретной задачи в конкретных условиях. Рекомендации даны с вариациями и опциями, чтобы учесть различия. Превратить относительно общие рекомендации в конкретные – уже ваша задача, как внедренца.
Ну чего я объясняю, если вы – программист 1С, то вы только тем и занимаетесь, что приспосабливаете типовое, общее и универсальное к конкретным реалиям. Тут то же самое.
Нет, не в этом. Многократная продажа – это один из примеров, до какой эффективности можно дойти, но только не этим кейсом. Считайте, что это пример из другой практики.
Важно, чтобы вы понимали – вариантов повышения эффективности бизнеса 1С: Франчайзи достаточно много, и результат они могут дать колоссальный – в десятки и сотни раз. Данный кейс – лишь один из вариантов, с весьма скромным результатом – вдвое.
Прекрасно, только лучше в виде отдельной статьи. Внимательно изучу и попробую применить, если эксперимент будет понятным по срокам и недорогим – как в этом кейсе.
Принципиальной разницы нет. На проекте есть специфика – наличие взаимосвязанных этапов, внутри которых – взаимосвязанные задачи. Но атомарная сущность остается прежней – задачи.
Задачи проекта всегда можно вывернуть в поток. В каком-то смысле они даже проще, чем разовые, т.к. сохраняется контекст и взаимосвязи – следовательно, можно получить еще более впечатляющий результат по ускорению, т.к. идет не только обмен опытом между программистами, но и накопление опыта за счет решения связанных задач.
Мы, кстати, именно на проектных работах проверяли в течение двух месяцев. Только проект был сделан «плоским» — в виде перечня задач, разделенных некими вехами.
Наибольший эффект достигается, если применить кейс к команде. Объясню в базовых терминах системного мышления.
И один программист, и пять, и сто – это система. В системе есть элементы и связи. В нашем случае программист – элемент. Взаимодействие, автоматизация, мотивация, цели, управление – это связи.
Для увеличения общей производительности системы воздействовать можно и на элементы, и на связи. Это очень важно понять, это ключ. Потому что все пытаются воздействовать на элементы – т.е. на программистов. Что-то сделать с программистом, чтобы он работал лучше. Это полезно, но не очень перспективно.
Потому что и у элементов, и у связей есть предельная производительность. Невозможно бесконечно улучшать только конкретного программиста, или только систему мотивации, или только менеджмент. Вы в любом случае увидите плато, после временного роста производительности.
Грубо говоря, у вас мало рычагов. Если программист один, то предел системы равен пределу элемента. Если залезть глубже, то можно и программиста представить, как систему, и найти в нем связи, но принцип остается на месте.
Если вы смотрите на свою систему, как на набор, т.е. кучку, атомарных элементов – программистов – то у вас почти нет возможностей для увеличения производительности. Если же вы увидите связи, и начнете на них воздействовать, то откроете для себя целый неизведанный мир, полный новых возможностей.
Если вы – владелец бизнеса, то ответ, вроде, очевиден. Хотите роста – надо что-то менять.
В бизнесе 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 – сказали: вот трекер, выбирай любую и делай. Что будет дальше?
Программист будет выбирать. В программном коде оператор выбора срабатывает за долю миллисекунды (если не очень сложное условие), но человек-то – не машина. Для него выбор – это процесс, который порой идет оооооочень медленно.
Иногда такой процесс напоминает разведку боем: программист не только читает заголовок задачи и детальное описание, но и комментарии, а потом – лезет в конфигуратор, чтобы понять контекст. Посмотрит, потыкается – фу, скажет, это задача про спецодежду, там черт ногу сломит, в этой УПП. Не, пусть Колян делает. Минут 15 потеряно. Умножаем на 10-20, сколько получится? До 5 часов?
Это ладно, если программист толковый, и ему достаточно контекста для принятия решения. А он, допустим, большой любитель интернета, и пошел искать готовое решение – на том же Инфостарте, или партнерской конференции, или еще где. Время выбора начинает расти с устрашающей скоростью.
Полдня будет выбирать, полдня будет работать. Потери – 50%, т.е. кому-то достаточно правильно выдавать задачу, чтобы повысить выработку вдвое.
Ладно, нет у нас такой проблемы, как выбор. Выбирает менеджер, или главный программист, и говорит – вот, эту делай. Нет, не хочу, не могу, пусть лучше Колян делает – отвечает программист. Делай, я сказал! – настаивает главный.
Дальше, по разумению главного, программист сел и делает. Пусть не очень эффективно, но делает. А что он делает? Иногда – да, решает задачу. Иногда – сидит и обижается. Или ищет причины не делать задачу. Например, готовит перечень вопросов, «без решения которых начинать бессмысленно». Или в интернет тупит, потому что мир не справедлив.
Примеры закончу, хотя их, на самом деле, десятки. Получается, есть два состояния у программиста – пишет код или тупит. Слово «тупит» использовано без негативной коннотации, просто не нашел более подходящего глагола от существительного «ступор».
Вот и главный принцип нарисовался: смотри туда, где тупит. Нет особого смысла начинать рост эффективности с процесса написания кода, выбора другой среды разработки (типа EDT), всяких приблуд для ускорения кодирования и т.д. Считайте, что когда программист пишет код – он эффективен. Вот прям когда пальцами на клавиатуре стучит, или мышкой формы рисует и реквизиты добавляет.
Основное время теряется там, где программист тупит, а не там, где он пишет код. Несколько вариантов я рассказал.
Если вы – руководитель программистов, перестаньте смотреть на написание кода, посмотрите на простои. Если вы – программист – посмотрите на себя, на свои простои. Это – ключ к повышению скорости разработки.
Возвращаемся к вопросу – каково идеальное время решения задачи клиента программистом 1С? Ответ очевиден – ноль. Ну ладно, совсем ноль не бывает, пусть будет 5 минут. Как достигается такое время? Вы уже понимаете: выдачей готового решения. Пришел клиент, сказал свою задачу, а вы ему сразу – решение, которое у вас уже есть. Сколько взять денег – не знаю, ну не за 5 минут работы специалиста, это точно. Можно спорить с этим утверждением, а можно задуматься. Сколько раз вы решали идентичные задачи? Каков процент задач, которые вы решаете в первый раз, и вообще о подобном не слышали? У меня практика небольшая – всего 13 лет, но даже с такой скромной цифрой я понимаю и вижу, что половину задач я уже решал.
Если вооружиться таким подходом, то потребуется совсем немного – писать абстрактные настраиваемые инструменты (вместо контекстного, сиюминутного говнокода) и где-то их хранить. Первое мы обсуждали, второе имеет массу вариантов решения.
Тут я немного вышел за рамки кейса. Я не призываю вас все бросить и заниматься готовыми решениями, просто хотел показать идеал – ускорение уже, по сути, не разработки, а продажи в десятки и сотни раз. Соответственно, и ускорение генерации дохода франча в сотни раз. Пока займемся чем помельче – вдвое ускоримся.
Принцип вы поняли, дальше вам будет все понятно и просто. Я опишу действия, которые надо включить в процесс работы отдела, с одной целью – уменьшить время тупежа, заместив его программированием.
Общее обсуждение входящих задач
Просто и банально. Дежурный, которого мы обсуждали в прошлой статье, каждое утро собирает всех программистов в кучу, и они дружно смотрят на новые задачи.
Первое, что надо выяснить – решал ли кто-то подобную задачу. Если решал, то назначить его консультантом, или куратором – не важно, как назвать. Важно, чтобы исполнитель знал, к кому обратиться.
Если такого никто не делал, то немного упрощаем критерии – ищем тех, кто работал с этой подсистемой, или этим документом, или этим механизмом платформы. Ну, понимаете – если задача про рисование Планировщика, то сойдет любой, кто уже смог осилить этот невероятный механизм. Он и будет консультантом.
Если задача вообще новая, и никому не знакома даже близко, то надо выбрать раскуривателя – того, кто будет в этой теме разбираться первым. Ключевых задачи две: решить задачу и наработать компетенцию. Чтобы в следующий раз стать консультантом по подобным задачам. Разумеется, всем понятно, что на раскуривание может уйти больше времени, чем согласовано с клиентом – это нормально, вы инвестируете в свою команду.
Наличие консультанта особенно важно для новичков. Даже если вы, по своей стратегии развития компетенций, запретите новичку спрашивать куратора, сам факт его наличия будет оказывать новичку колоссальную моральную поддержку.
Ну и не забудем дать оценку задаче, в баллах – сыграть в покер планирования.
Выбор исполнителя по компетенциям в соответствии со стратегией
Тут все просто. Вы сделали выбор – отрегулировали ползунок между выработкой и повышением компетенций. Вот и выбирайте исполнителя в соответствии со своей стратегией.
Например, вы решили, что новички должны решать незнакомые задачи 30 % времени. В системе у вас уже есть отчет, который показывает процентное соотношение – сколько знакомых, сколько незнакомых задач он решал. Смотрите на цифры и решайте, в какой момент выдать новую, незнакомую задачу.
Наличие консультанта снимет избыточный потенциал важности с задачи, и придаст процессу элементы игры. Новичку будет интересно разобраться с новыми механизмами, потому что он будет знать о наличии поддержки, чувствовать ее. Если вы заранее оговорите границы применения этой поддержки, будет вообще замечательно: например, дадите новичку на самостоятельную работу не более одного дня, после чего решением займется консультант.
Степень и формат поддержки от консультанта выбирайте сами, тут ничего сложного. Если новичок – совсем новый, то нет смысла давать ему ссылку на партнерскую конференцию, толстую книгу по разработке и подбадривать «давай, разбирайся, сынок». Такой большой кусок он просто не сможет переварить, подавится, и вы можете потерять сотрудника. Он не уволится, но получит существенный удар по своей значимости, может стать закрытым и инертным.
Однозначных советов по выбору «размера куска» нет, потому что все строго индивидуально. Универсален один принцип: за этим размером нужно следить. Разумеется, если вы хотите эффективность повысить, а не собственную значимость. Такой способ самовыражения, как постановка нерешаемых задач, в среде программистов 1С слишком широко применяется, чтобы не говорить о нем.
Есть и исключения – сотрудники, которые хотят во всем разобраться самостоятельно. Настолько хотят, что наотрез отказываются от любой помощи. Это их способ повышения значимости – «я могу разобраться сам», и чем шире контекст, в который он вникнет, тем больше награда – самоудовлетворение. Это полезное качество, но оно иногда в манию переходит – лучше за таким следить, ставя границы (по времени, например).
Если задача срочная, или клиент для вас важен, то эксперименты выключаются, и на задачу садится тот, кто лучше всех разбирается. Ну, это всем понятно.
Управление взаимопомощью и ее учет
Раз есть консультант, неплохо бы его замотивировать – дать процент от почасовой оплаты за решение задачи. Размер процента зависит от степени участия.
Разумеется, надо сделать так, чтобы консультант не наглел, и не тянул одеяло на себя, когда задача назначена новичку. Не забываем, что наша цель – не сиюминутная выгода, а долгосрочный успех.
Ну и за новичком надо следить. Если вы решили, что он в данной задаче познает только работу с Планировщиком, не позволяйте ему брать на себя весь остальной контекст задачи – пусть его расскажет консультант.
Собственно, тут больше нечего добавить.
Управление статусами задач
По этой теме была отдельная статья, все повторять не буду. Статья, кстати, не особо заинтересовала 1Сников, но пришлась по вкусу представителям других рас разработчиков – мы с ними активно работаем теперь. Это я к тому, что в мире программирования 1С пока не все хорошо с методами повышения эффективности.
Когда выберете дежурного, дайте ему ссылку на статью, приведенную выше. Главное, что он должен понять, принять и исполнять – за статусами задач нужно следить.
Каждое его утро должно начинаться с ритуала – управления статусами задач. Это очень просто и легко автоматизируется. В первом окне – новые задачи, еще не принятые в работу. Это – список для обсуждения с командой, которое мы рассмотрели выше. Итогом обсуждения должно стать опустошение этого окна.
Во втором окне – задачи, принятые в работу, но не имеющие исполнителя. Опустошается так же, после общего обсуждения. По итогам обсуждения оба списка должны стать пустыми. Допустимое время нахождения задачи в статусах «Не принято в работу» и «Не назначен исполнитель» — не более одного рабочего дня.
Если задача не понятна, и требуется уточнение заказчика – задача, вместе со списком вопросов, переезжает в окно/статус «Требуется уточнение» или «Отправлено на доработку» — не важно, как назвать. Важна детерминированность.
После обсуждения (или перед ним) дежурный проверяет список отправленных на доработку, чтобы не было просрочки статусов. Например, на уточнение постановки отводится три дня. Прошло три дня – надо написать заказчику, чтобы не тормозил. Он, с высокой вероятностью, просто забыл ответить.
Во время обсуждения с программистами смотрим на окно «В работе». Оно у нас ранжированное: все понимают, кто какой задачей занимается. Соответственно, есть время нахождения задачи в статусе «В работе», с привязкой к исполнителю, и это время надо контролировать.
Банально – для того, чтобы не пропустить границу времени познания для новичка. Если ему дали сутки на самостоятельное решение, и эти сутки прошли, то он, с высокой вероятностью, не поднимет руку и не скажет, что не справился. Будет тупить до последнего. Нам это не надо, поэтому банальный контроль за временем жизни статуса спасет от лишних потерь, а новичка – от чувства вины за свою тупость.
Последнее окно – выполненные задачи, требующие акцепта от заказчика. Тут принцип такой же, как в отправленных на доработку – ставим срок, например, три дня, после которого начинаем напоминать о себе. Спокойно, уверенно, но настойчиво. Повторю, заказчик мог просто забыть, у него своих дел хватает.
Финал
Ну все, заканчиваем кейс. Главная цифра, о которой шла речь – внутренняя стоимость единицы работ, т.е. балла. Я утверждал, что можно эту стоимость снизить вдвое – производить то же количество работ за вдвое меньшее время.
Вот наш график, по одному из клиентов (ключевому на данный момент):
Как видите, до применения кейса (т.е. до апреля) стоимость балла болталась примерно на одном уровне. Это означает, что, тратя одно и то же количество часов, мы производили одно и то же количество результата – в среднем 1 балл за 0.9 часа.
В первый месяц применения кейса стоимость балла резко упала, до 0.22 часов, это примерно в четыре раза. Первый месяц, конечно, стоит учитывать, но ему нельзя доверять полностью, потому что там был резкий скачок сдачи работ – закрылось несколько «дорогих» задач, которые из-за неуправляемого жизненного цикла задач тянулись, как резина.
Второй месяц – более показательный и правильный. Во-первых, уже не было старых задач, которые бы закрылись – все задачи, закрытые в мае, родились в предыдущие два месяца, т.е. во время применения кейса. Во-вторых, применение кейса устаканилось и вошло в привычку. Итог – 0.33 часа за 1 балл, что в три раза лучше, чем было до кейса.
Ну а дальше цифра стала болтаться в районе обещанного среднего — половины от исходного.
Разумеется, положительные результаты получились не только по этому клиенту, но и в целом по всем работам. В том числе – по внутренним, которых у нас достаточно много – больше, чем для внешних клиентов.
Вот, например, график суммарного количества произведенных баллов:
Как видите, до кейса мы в среднем выдавали 400-500 баллов в месяц, а потом эта цифра выросла до 1400 – прирост в 3 раза.
Оба графика обрезаны октябрем, увы — мы раньше вели задачи в гитхабе, а потом переехали в Flowcon. Общий график, из двух источников, рисовать лень.
Здесь интересно понять зависимость цифр. Мы, Окнософт, стараемся мало заниматься услугами для клиентов, наш приоритет – разработка. До применения кейса у нас была проблема – на клиентов уходило слишком много времени, а на разработку оставалось очень мало.
Применение кейса позволило нам из этой ловушки выбраться – у нас появилось, пусть еще недостаточно, но намного больше времени на развитие. Результат не заставил себя ждать: мы реализовали несколько очень важных для нас продуктов.
Первый – сайт нашего проекта по бизнес-программированию (ссылку не буду давать, а то опять получу письмо с темой «nmivan, пройдемте...»). Ключевое слово — сайт, потому что раньше мы делали только бизнес-приложения, работающие через интернет. Сайт сделан на платформе metadata.js, но ключевым успехом является не сам сайт, и не контент, а доработка платформы и ее компонентов. Теперь на metadata.js можно делать еще и сайты. Причем, сайт содержит функциональность CMS и микросервисы.
Второй проект, до которого долго не доходили руки – безбумажка, т.е. функциональность цеховой диспетчеризации, работающая через браузер и с крутой визуализацией (это важно для оконного производства, например). Работа безбумажки через браузер – например, использование сканера штрихкодов, подключенного к телевизору – значительно расширит и упростит возможности применения решений на metadata.js в производстве. Особенно с учетом простоты работы с внешними событиями в коде metadata.js – их можно ловить в любом месте, а не только в активной форме, как в 1С.
Про третий проект рассказывал — Flowcon.Life. Для нас он крайне важен, т.к. дал кучу полезных задач по развитию платформы. Это первый проект для людей, а не для бизнеса.
Четвертый вам вряд ли интересен — это Flowcon, конфигурация для 1С + сервис управления задачами/командой/бизнесом.
Ну и еще несколько — либо поменьше и поскучнее, либо побольше и посекретнее. Итого, допустим, шесть штук.
Много это или мало? Уточню — для двух человек. Которые еще и с клиентами работают на проектах внедрения, статьи пишут, много ругаются друг с другом и со всем миром, да еще и ленивые до чертиков.
Все познается в сравнении. Шесть проектов за 9 месяцев – много или мало? Если вспомнить, что за предыдущие 6 месяцев проект был один (сервис параметрических заказов), то прирост значительный – с 0.15 проекта в месяц до 0.66 проектов в месяц.
Для нас эти проекты ценнее, чем отгруженные часы, потому что они нас развивают — все, что мы вкладываем в понятие Окнософт. Платформу, продуктовую линейку, каналы продаж, функциональность тиражных решений. В отличие от отгруженных часов, единственный выхлоп которых – деньги.
Конечно, проекты все разные по сложности и трудозатратам, и только по их количеству судить сложно. Поэтому мы и используем несколько цифр, которые я привел, чтобы понимать свое состояние и динамику максимально адекватно.
Видя комплексную оценку, мы понимаем, что кейс работает и приносит реальную пользу бизнесу, причем – очень быстро. В нашем случае этого кейса мало, потому что, как вы поняли, наш приоритет – разработка.
Кстати, это и есть тот самый экзотический сценарий использования ускорения. Мы вот не стали больше услуг продавать клиентам, а потратили освободившееся время на новые продукты. Не знаю, правы мы или нет, время покажет — может, и правда надо думать только о сегодняшнем дне? Как большинство франчей делают.
Ну, про нас поговорили, теперь про вас. Я уверен, что у вас при чтении статьи возникли вопросы. Тема ускорения для меня не новая, поэтому часть вопросов, которые вы захотите задать, я много раз слышал, и отвечу на них сразу. Вопросы сгруппирую.
«Не верю»
Вера не требуется. Если вы считаете, что вам нужна вера, то с вами что-то не так.
Вера была бы нужна, если бы я вам чего-то продать пытался – консалтинг, книжку, семинар или членство в клубе. Тогда и у меня был бы мотив вашу веру взращивать. Но я вам ничего не продаю, поэтому вопрос веры – сугубо ваш личный, он субъективен и никак со мной не связан.
Ну и вообще, у нас тут кейс, а не секта. У нас – бизнес, у вас – тоже. Наш бизнес вашему ничего не должен, как и ваш – нашему. Причем, верить тоже не должен.
Вот когда один программист 1С придумал, как ускорить проведение документов вдвое, и изложил этот способ, нужна ли второму программисту 1С вера, чтобы попробовать применить тот же способ? Не исключаю, конечно, что кому-то нужна, но большинству – нет.
Ставишь копию базы, вносишь предложенные изменения, смотришь на результат. Получилось вдвое – круто. Получилось в 1.5 раза – круто. Не изменилось или стало хуже – пишешь автору. Он или попробует помочь, и сделает свой способ более абстрактным, или скажет «пф, мне-то что, у меня получилось».
Что плохого случится со вторым программистом 1С? Ничего. Даже если результата не будет, он просто потратит немного времени – причем, с пользой.
С кейсом ситуация ровно та же. Как я говорил в первой статье, затраты на его внедрение – ничтожны. Большинство методов вообще внедряются бесплатно. Покупать ничего не требуется, в том числе у нас.
Зачем тогда вера?
«А ты покажи, докажи»
Что смог – показал. Про «доказать» — см. выше, про веру, смысл один и тот же.
Доказательство – это очень трудоемкий процесс, и цель его – собственно, доказательство. У меня такой цели нет, я же не диссертацию защищаю. Доказать вы можете сами себе, если попробуете. Я вам ничего доказать не смогу.
Даже не смогу доказать, что у нас кейс сработал. Элементарно – вы скажете, что я графики от балды нарисовал. И какие бы цифры, отчеты, выписки со счета или из налоговой я не привел, вы сможете сказать – «пф, а причем тут кейс вообще?».
Понимаете? Доказательство, вера и т.д. – это ваше личное, внутреннее, не имеющее ко мне никакого отношения. Это стереотип такой, внутреннее убеждение, особенность восприятия, а скорее всего – способ самозащиты: не буду ничего менять и делать, пока мне не дадут веру и не докажут. Звучит понятно и правильно, но полностью обрубает возможность изменений, по одной простой причине – никто не собирается вам ничего доказывать.
«Нет смысла, ничего не получится»
Если не пробовать – да, не получится. Тоже способ самозащиты. Непонятно только, от кого.
«Ерунда все это, детский сад какой-то, это не работает»
Вот это самое забавное, на мой взгляд. Кого вы пытаетесь убедить, что это не работает? Меня? Так у меня работает.
Если бы я писал кейс о том, как «можно было бы поработать», то смысл в таких утверждениях был бы – предупредить меня о том, что я занимаюсь ерундой.
Если вы пытаетесь убедить остальных читателей, то ваши цели мне не понятны. Не буду оспаривать их важность и ценность, просто не понимаю. Вам какое дело до остальных?
Если пытаетесь убедить себя, то у вас отлично получается.
«У нас совсем другая проблема – вот такая и вот такая»
Прекрасные и очень полезные комментарии. Я обязательно учту их в своей работе – мне важно знать о том, что вас беспокоит и в чем есть проблемы.
«Автору надо посмотреть фильм/почитать книгу/поспать/помолчать/попрограммировать»
Что надо делать автору – не имеет никакого значения. За ссылки и наводки, разумеется, спасибо.
«Решать надо совсем другие проблемы, а не обозначенную»
Если убрать противопоставление, то – отличный комментарий. Решать надо все проблемы, так или иначе. Вопрос в приоритетах, а они – субъективны для каждого бизнеса и человека.
Кейс направлен на решение конкретной задачи в конкретных условиях. Рекомендации даны с вариациями и опциями, чтобы учесть различия. Превратить относительно общие рекомендации в конкретные – уже ваша задача, как внедренца.
Ну чего я объясняю, если вы – программист 1С, то вы только тем и занимаетесь, что приспосабливаете типовое, общее и универсальное к конкретным реалиям. Тут то же самое.
«Речь только о многократной продаже решений? В этом смысл?»
Нет, не в этом. Многократная продажа – это один из примеров, до какой эффективности можно дойти, но только не этим кейсом. Считайте, что это пример из другой практики.
Важно, чтобы вы понимали – вариантов повышения эффективности бизнеса 1С: Франчайзи достаточно много, и результат они могут дать колоссальный – в десятки и сотни раз. Данный кейс – лишь один из вариантов, с весьма скромным результатом – вдвое.
«Вообще не так надо работать, а вот так…»
Прекрасно, только лучше в виде отдельной статьи. Внимательно изучу и попробую применить, если эксперимент будет понятным по срокам и недорогим – как в этом кейсе.
«Это про проекты или про разовые работы?»
Принципиальной разницы нет. На проекте есть специфика – наличие взаимосвязанных этапов, внутри которых – взаимосвязанные задачи. Но атомарная сущность остается прежней – задачи.
Задачи проекта всегда можно вывернуть в поток. В каком-то смысле они даже проще, чем разовые, т.к. сохраняется контекст и взаимосвязи – следовательно, можно получить еще более впечатляющий результат по ускорению, т.к. идет не только обмен опытом между программистами, но и накопление опыта за счет решения связанных задач.
Мы, кстати, именно на проектных работах проверяли в течение двух месяцев. Только проект был сделан «плоским» — в виде перечня задач, разделенных некими вехами.
«Речь о выработке одного или нескольких программистов?»
Наибольший эффект достигается, если применить кейс к команде. Объясню в базовых терминах системного мышления.
И один программист, и пять, и сто – это система. В системе есть элементы и связи. В нашем случае программист – элемент. Взаимодействие, автоматизация, мотивация, цели, управление – это связи.
Для увеличения общей производительности системы воздействовать можно и на элементы, и на связи. Это очень важно понять, это ключ. Потому что все пытаются воздействовать на элементы – т.е. на программистов. Что-то сделать с программистом, чтобы он работал лучше. Это полезно, но не очень перспективно.
Потому что и у элементов, и у связей есть предельная производительность. Невозможно бесконечно улучшать только конкретного программиста, или только систему мотивации, или только менеджмент. Вы в любом случае увидите плато, после временного роста производительности.
Грубо говоря, у вас мало рычагов. Если программист один, то предел системы равен пределу элемента. Если залезть глубже, то можно и программиста представить, как систему, и найти в нем связи, но принцип остается на месте.
Если вы смотрите на свою систему, как на набор, т.е. кучку, атомарных элементов – программистов – то у вас почти нет возможностей для увеличения производительности. Если же вы увидите связи, и начнете на них воздействовать, то откроете для себя целый неизведанный мир, полный новых возможностей.
«Зачем?»
Если вы – владелец бизнеса, то ответ, вроде, очевиден. Хотите роста – надо что-то менять.
В бизнесе 1С: Франчайзи, правда, можно ничего и не менять, потому что есть «мама», которая что-то сделает за вас. Новые продукты, рынки, сервисы. Тогда вы сможете расти, ничего не меняя – просто вслед за ростом рынка, сохраняя свою долю в нем.
Если вам достаточно темпа роста рынка, то все в порядке. Нам – не достаточно, мы хотим эти темпы обгонять. И создавая новые рынки, и увеличивая свою долю на старых, и меняя структуру рынков.
Если помните (я, почему-то, запомнил), была такая позиция у 1С: конкурируйте не ценой, а качеством. Качество – это внутренняя характеристика, причем – конкретно вашего бизнеса. Качество вашей работы никак не зависит от «мамы» и конкурентов.
Весь кейс – про производительность. Производительность – один из показателей качества системы. Все, как «мама» велела.
