Хабрахабр

1С, не болей

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

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

Там работает куча прекрасных людей, но то ли среда такая, то ли место проклятое — с ними что-то не так. Так что в списке «Самые неразвивающиеся компаниии» остаются только франчайзи 1С.

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

Можно сделать лучше. Но мне, почему-то, кажется, что не все потеряно.

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

Знакомый он нам потому, что есть опыт работы в других франчах в течение нескольких лет, плюс – мы постоянно с франчами сталкиваемся, в формальной и неформальной обстановке. Попробуем сформировать кейс для конкретной части знакомого нам бизнеса – 1С: Франчайзи.

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

Если вы не знаете, что такое 1С: Франчайзи, то читайте так, будто речь о некой компании, оказывающей услуги по разработке, сопровождению и доработкам ПО.

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

Исходная ситуация

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

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

Общая среднемесячная выработка составляет 500 часов. Допустим, наш отдел разработки состоит из пяти человек. 100 часов закрывает Второй, по 80 – Третий и Четвертый, 40 – Новичок. Из них 200 закрывает некий Чемпион – самый опытный и толковый кодер.

Допустим, у нас единая внутренняя ставка для программистов – 500 рублей в час. Допустим, час работ для клиента стоит 2000 рублей. рублей в месяц, ФОТ отдела – это просто 25 % от выручки, в данном случае – 250 тыс.рублей. Простые подсчеты говорят, что выручка отдела – 1 млн. рублей, из которых платит налоги на тех же программистов, ну и все свои остальные расходы. Итого, компания получает 750 тыс. содержит постоянные расходы, вроде аренды офиса и покупки печенек. Структуру прибыли рассматривать не будем, просто понимаем, что она нелинейная, т.к.

Разве что, когда Чемпион уходит в отпуск, имеем провал процентов на 40. Выработка, допустим, относительно стабильная, сильно не прыгает. Иногда случается и 700 часов — когда случился хороший проект, и программисты работают по выходным.

Цель кейса

Сразу цель применения кейса расскажу, чтобы не создавать таинственности. Мы хотим, чтобы наш отдел разработки выдавал не 500, а 1000 часов в месяц, т.е. вдвое больше. За ту же часовую ставку, с теми же постоянными затратами, с тем же количеством рабочих часов. Можем допустить небольшие временные расходы на этот проект – допустим, в пределах 30-50 т.р.

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

За эти 500 часов они решают, допустим, 200 задач, со средним ценником 2. Допустим, наши 500 часов в месяц – это 500 реальных часов работы специалистов. Получается, каждая задача в среднем стоит 5000 рублей. 5 часа. Клиент вполне готов платить такие деньги, он знает рынок, у остальных франчей цена такая же.

5 часа, а за 1. И вот мы научились решать задачу не за 2. Ключевой вопрос – почём ее продать клиенту? 25 часа.

25 часа. Если мы продаем время, то логично продать за 1. Но нам, как бизнесу, от такой схемы выгоды почти нет – только довольный клиент и свободное время специалистов, которое надо чем-то занять. Клиент будет чертовски доволен – и дешевле, и быстрее. 25 часа. Допустим, мы нашли еще клиентов, и тоже продаем им задачу по 1. Те же 500 часов по 2000 рублей. В итоге, за месяц, что мы получим? Смысла нет.

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

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

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

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

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

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

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

Ключевая проблема

Говорят, всегда есть точка приложения силы, в которую надо вставить рычаг и получить максимальный эффект. Я с этим не согласен – в смысле, что такая точка есть всегда. Но в данном кейсе она есть – система мотивации.

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

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

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

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

Если специалисты не делятся компетенциями, то забота об обучении ложится на плечи компании. Что в этом для бизнеса? Второе – узкие места в виде ключевых специалистов. Надо организовывать курсы, либо платить сторонним организациям (вроде 1С). Даже если это Чемпион, будет не более 200 часов в месяц. Если из 5 человек только один знает ERP (это тоже программа такая), то вы физически не можете брать работ по ERP больше, чем этот сотрудник способен переварить. Ну либо рисковать — работы брать, чтобы разобраться потом, по ходу.

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

Индивидуальная часовая ставка – это как бизнес внутри бизнеса, причем этот «внутренний бизнес» — всегда ИП, а не ООО.

Бывает, конечно, затишье в пару лет – например, перед выходом ERP, когда уже все разобрались в УПП (это тоже программа, старенькая, но бодрая). А компетенции важны, особенно в эпохи перемен, которые периодически случаются. Сейчас, наверное, знатоки ERP лучше всех живут – точно не знаю. Но в 2004 – 2010 годах, например, лучше всех жили «проектники», которые владели знаниями по УПП.

Ну отдал ты человеку свою обработку или подсистему, он закрыл за день оговоренные с клиентом 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 часа. Одна – реальные затраты времени, другая – некая оценка для клиента. Сейчас, в текущем состоянии, считаем, что эти оценки равны (в среднем).

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

Каждая задача оценивается в баллах, взятых из ряда Фибоначчи – 1, 2, 3, 5, 8, 13, 21, 34 и т.д. Я рекомендую систему из Scrum – покер планирования. Оценка отражает ваше комплексное видение этой задачи – и сложность исполнения, и трудозатраты, и неизвестность, и проблемность клиента на сдаче работ.

Это – самая простая, атомарная задача, из тех, что вы решаете. Проще всего начать с «якоря» – определить, что есть задача в 1 балл. Соответственно, задача в 2 балла – сложнее вдвое.

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

У нас не Scrum, правила пишем сами. Если вы внедряете систему «сверху», то вполне можно не устраивать голосований, а ставить оценки самому.

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

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

Я такой вариант не рекомендую, но мое мнение можно игнорировать. Если вам не нравятся баллы, то можно использовать какой-то вариант нормо-часов. Например, на заре практики я придумал такую оценку, как «по лучшему» — сколько часов потратил бы на решение задачи лучший программист, который все знает о задаче, контексте, клиенте, функционале и т.д… Все, что надо такому «лучшему» — написать код.

Во-первых, потренируетесь и выработаете свою систему оценок. Теперь крайне важно ввести начальные остатки – оценить задачи за 1-2 месяца, которые вы уже решили, и внести оценки в систему. Во-вторых, и самое главное – получите текущую скорость и «цену балла».

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

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

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

Если вы внедряете систему «сверху», то идеальный вариант – сделать ввод начальных остатков тайком от программистов.

Система компетенций

Система учета компетенций настолько важна, насколько и не распространена. Записи о количестве сертификатов, разумеется, системой учета компетенций не являются (равно как и сертификаты не являются компетенциями).

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

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

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

В ней перечисляются элементы справочника, и ставится оценка. В информационной системе, в объекте задачи должна появиться табличная часть – компетенции. Сам я ставил единичку, и считал компетенцию уверенной после набора 10 единичек. Что за оценка – не знаю, вам решать. Вы можете ставить проценты, и считать компетенцию подтвержденной, если набралось 100 %.

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

Ну и отчет в придачу, который план-факт сделает. Можно добавить в систему некий «План компетенций», в котором вы перечислите приоритеты развития и должный уровень компетенций по каждому сотруднику. Особенно интересно смотреть дисперсию роста компетенций – вполне возможно, что ваш чемпион работает только по основной, или единственной, изученной области, популярной на данный момент среди клиентов.

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

Система мотивации

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

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

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

Такая система часто встречается у продавцов, когда один, например, притащил клиента, а второй сопровождал сделку.

Допустим, человеку досталась задача, а он плохо разбирается или в технике, или в методике, или во всем сразу. В нашем случае основной мотив использования КТУ – «раскрутить» чемпионов, да и вообще всех, на сотрудничество. Но знает, что другой парень решал подобную задачу (или не знает, а уверен – если посмотрел отчет по компетенциям).

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

Исполнитель подходит к «знающему», предлагает сотрудничество. Теперь же будет по-другому. Сколько хочешь? «Знающий» говорит – там делов на пару часов, у меня и пример есть, надо немного доточить, и все. Ну, давай 40 % — говорит «знающий». – спрашивает исполнитель. х 2 ч. Исполнитель соглашается, за 15 минут получает наводку и ликбез, а заодно и примеры кода, решает задачу за 2 часа, получает 500 р. на этом отрезке лично для себя он сработал по 266 рублей в час (600 рублей за 2. х 60% = 600 рублей, т.е. Если бы делал сам, сработал бы по 100 рублей в час (потратил бы 10 часов, получил бы 1000 рублей). 25 часа).

Ну, на то он и знающий. «Знающий» сработал по 1600 рублей в час (потратил 15 минут, получил 400 рублей). свой труд и свое время, он продает по 500 рублей в час, а свои реальные знания – по 1600 рублей в час. Обычные работы, т.е. Клиент получил решение быстро, ничего не потеряв в деньгах. Никто не в минусе, большинство – в плюсе. Исполнитель рад до ушей, а знающий, наконец-то, начал получать дивиденды от своих инвестиций в самообразование. Компания ничего не потеряла в деньгах, получила двух довольных сотрудников и довольного клиента.

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

Пусть сами договариваются, они ведь взрослые люди. Главное, на мой взгляд – полностью отдать распределение процентов программистам, и не вмешиваться в него.

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

Стратегия по компетенциям

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

Второй вектор дает минимальную скорость решения, но максимальный рост компетенций. Первый вектор дает максимальную скорость решения, но не дает развития компетенций.

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

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

Понятно, что речь о сумме оценок задач. Для начала можно выставить такие значения: 70 % – на задачи по развитым компетенциям, 30 % – на задачи по новым областям знаний. Даже, для простоты, выделить день в неделе на задачи по развитию. Хотя, можно и время в процентном соотношении делить.

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

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

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

Назначить дежурного

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

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

Это не сложно, надо лишь встать и сказать что-то вроде «Так, все, бросаем работу, обсуждаем задачи. Дежурный будет, например, организовывать обсуждение входящего потока задач. Федя, хорош, потом покуришь. Давайте, их всего три на сегодня. В смысле „лучше сейчас не отвлекаться“? Колян, потом доделаешь. Блин, парни, договорились же, вы все башкой кивали, что в 9-00 у нас обсуждение задач. Мы тебя ждать все будем? Решили – надо делать, иначе нет смысла». Давайте, не валандайтесь.

Дежурный управляет статусами задач. Дежурный отвечает за качество данных в системе – например, за правильное указание компетенций (и вообще за их указание).

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

В команде из 5 человек будет уходить минут 15 в день. Через какое-то время выполнение правил войдет в привычку, и дежурить станет просто. По ходу придумаете, как автоматизировать часть контроля правил – вы же программисты.

Поговорить с программистами

Этот пункт – опциональный, необходимость в нем зависит от того, кто вы. Лично я рекомендую все-таки с программистами поговорить, объяснить перспективы и суть изменений. Обязательно дайте им почитать про комплект увольнения. Хорошо, если вам удастся программистов вдохновить. Если вы раньше устной мотивацией не занимались, то получите полезный опыт, особенно если делаете это не «в первый и последний раз».

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

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

Заранее решите, что у вас не получится убедить программистов, тогда и не расстроитесь. Если не получится вдохновить – не расстраивайтесь. Тогда станут вам помогать. Они вдохновятся сами, когда увидят результат – рост выработки и, соответственно, доходов.

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

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

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

Главный принцип

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

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

Речь о задаче на разработку или доработку. Какова, по-вашему, идеальная скорость решения задачи клиента программистом 1С? Подумайте, пока читаете, ответ будет чуть ниже.

Как думаете, сколько процентов времени он, собственно, программирует (включая все аспекты – написание кода, создание метаданных, макетов и т.д.)? Давайте присмотримся к работе программиста 1С. 50 %? 100 %? 20 %?

Если не верите, проверьте на себе – есть специализированные программы для таких измерений. Практика показывает, что бывает и 3 %. Получившаяся цифра может вас удивить. Но есть способ проще – посмотрите на объем кода, написанный программистом за день, и разделите на его скорость печати.

Есть задачи, где надо тупо и много писать. Разум программиста возмутится – ну как же, причем тут вообще объем кода и скорость печати? А есть такие, где надо много читать, думать, анализировать и пробовать, долго отлаживать.

Весь день программист думал, анализировал, пробовал. Ок, зайдем с другой стороны. Хороший, правильный код, все проверено и работает. В итоге написал 50 строк кода, и задача решена. Потратил 8 часов.

Если просто возьмет готовое решение, то минут 5, верно? Теперь вопрос: за какое время он решит точно такую же задачу от другого клиента? А если заново написать, ручками? Ну, пока там конфигуратор откроется, пока второй, пока скопирует и т.д. По дороге еще и ревью сделает, на автомате, и код улучшит. Полчаса? В 16 раз быстрее.

Другой пример. Ладно, черт с ним, с копированием кода. Что будет дальше? Вы, вместо того, чтобы дать программисту одну задачу, дали 10-20 – сказали: вот трекер, выбирай любую и делай.

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

Посмотрит, потыкается – фу, скажет, это задача про спецодежду, там черт ногу сломит, в этой УПП. Иногда такой процесс напоминает разведку боем: программист не только читает заголовок задачи и детальное описание, но и комментарии, а потом – лезет в конфигуратор, чтобы понять контекст. Минут 15 потеряно. Не, пусть Колян делает. До 5 часов? Умножаем на 10-20, сколько получится?

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

Потери – 50%, т.е. Полдня будет выбирать, полдня будет работать. кому-то достаточно правильно выдавать задачу, чтобы повысить выработку вдвое.

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

Пусть не очень эффективно, но делает. Дальше, по разумению главного, программист сел и делает. Иногда – да, решает задачу. А что он делает? Или ищет причины не делать задачу. Иногда – сидит и обижается. Или в интернет тупит, потому что мир не справедлив. Например, готовит перечень вопросов, «без решения которых начинать бессмысленно».

Получается, есть два состояния у программиста – пишет код или тупит. Примеры закончу, хотя их, на самом деле, десятки. Слово «тупит» использовано без негативной коннотации, просто не нашел более подходящего глагола от существительного «ступор».

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

Несколько вариантов я рассказал. Основное время теряется там, где программист тупит, а не там, где он пишет код.

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

Ответ очевиден – ноль. Возвращаемся к вопросу – каково идеальное время решения задачи клиента программистом 1С? Как достигается такое время? Ну ладно, совсем ноль не бывает, пусть будет 5 минут. Пришел клиент, сказал свою задачу, а вы ему сразу – решение, которое у вас уже есть. Вы уже понимаете: выдачей готового решения. Можно спорить с этим утверждением, а можно задуматься. Сколько взять денег – не знаю, ну не за 5 минут работы специалиста, это точно. Каков процент задач, которые вы решаете в первый раз, и вообще о подобном не слышали? Сколько раз вы решали идентичные задачи? У меня практика небольшая – всего 13 лет, но даже с такой скромной цифрой я понимаю и вижу, что половину задач я уже решал.

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

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

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

Общее обсуждение входящих задач

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

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

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

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

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

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

Выбор исполнителя по компетенциям в соответствии со стратегией

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

В системе у вас уже есть отчет, который показывает процентное соотношение – сколько знакомых, сколько незнакомых задач он решал. Например, вы решили, что новички должны решать незнакомые задачи 30 % времени. Смотрите на цифры и решайте, в какой момент выдать новую, незнакомую задачу.

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

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

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

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

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

Управление взаимопомощью и ее учет

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

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

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

Собственно, тут больше нечего добавить.

Управление статусами задач

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

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

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

Опустошается так же, после общего обсуждения. Во втором окне – задачи, принятые в работу, но не имеющие исполнителя. Допустимое время нахождения задачи в статусах «Не принято в работу» и «Не назначен исполнитель» — не более одного рабочего дня. По итогам обсуждения оба списка должны стать пустыми.

Важна детерминированность. Если задача не понятна, и требуется уточнение заказчика – задача, вместе со списком вопросов, переезжает в окно/статус «Требуется уточнение» или «Отправлено на доработку» — не важно, как назвать.

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

Оно у нас ранжированное: все понимают, кто какой задачей занимается. Во время обсуждения с программистами смотрим на окно «В работе». Соответственно, есть время нахождения задачи в статусе «В работе», с привязкой к исполнителю, и это время надо контролировать.

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

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

Финал

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

Вот наш график, по одному из клиентов (ключевому на данный момент):

до апреля) стоимость балла болталась примерно на одном уровне. Как видите, до применения кейса (т.е. 9 часа. Это означает, что, тратя одно и то же количество часов, мы производили одно и то же количество результата – в среднем 1 балл за 0.

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

Во-первых, уже не было старых задач, которые бы закрылись – все задачи, закрытые в мае, родились в предыдущие два месяца, т.е. Второй месяц – более показательный и правильный. Во-вторых, применение кейса устаканилось и вошло в привычку. во время применения кейса. 33 часа за 1 балл, что в три раза лучше, чем было до кейса. Итог – 0.

Ну а дальше цифра стала болтаться в районе обещанного среднего — половины от исходного.

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

Вот, например, график суммарного количества произведенных баллов:

Как видите, до кейса мы в среднем выдавали 400-500 баллов в месяц, а потом эта цифра выросла до 1400 – прирост в 3 раза.

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

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

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

Ключевое слово — сайт, потому что раньше мы делали только бизнес-приложения, работающие через интернет. Первый – сайт нашего проекта по бизнес-программированию (ссылку не буду давать, а то опять получу письмо с темой «nmivan, пройдемте...»). Теперь на metadata.js можно делать еще и сайты. Сайт сделан на платформе metadata.js, но ключевым успехом является не сам сайт, и не контент, а доработка платформы и ее компонентов. Причем, сайт содержит функциональность CMS и микросервисы.

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

Life. Про третий проект рассказывал — Flowcon. дал кучу полезных задач по развитию платформы. Для нас он крайне важен, т.к. Это первый проект для людей, а не для бизнеса.

Четвертый вам вряд ли интересен — это Flowcon, конфигурация для 1С + сервис управления задачами/командой/бизнесом.

Итого, допустим, шесть штук. Ну и еще несколько — либо поменьше и поскучнее, либо побольше и посекретнее.

Уточню — для двух человек. Много это или мало? Которые еще и с клиентами работают на проектах внедрения, статьи пишут, много ругаются друг с другом и со всем миром, да еще и ленивые до чертиков.

Шесть проектов за 9 месяцев – много или мало? Все познается в сравнении. 15 проекта в месяц до 0. Если вспомнить, что за предыдущие 6 месяцев проект был один (сервис параметрических заказов), то прирост значительный – с 0. 66 проектов в месяц.

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

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

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

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

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

«Не верю»

Вера не требуется. Если вы считаете, что вам нужна вера, то с вами что-то не так.

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

У нас – бизнес, у вас – тоже. Ну и вообще, у нас тут кейс, а не секта. Причем, верить тоже не должен. Наш бизнес вашему ничего не должен, как и ваш – нашему.

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

Получилось вдвое – круто. Ставишь копию базы, вносишь предложенные изменения, смотришь на результат. 5 раза – круто. Получилось в 1. Он или попробует помочь, и сделает свой способ более абстрактным, или скажет «пф, мне-то что, у меня получилось». Не изменилось или стало хуже – пишешь автору.

Ничего. Что плохого случится со вторым программистом 1С? Даже если результата не будет, он просто потратит немного времени – причем, с пользой.

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

Зачем тогда вера?

«А ты покажи, докажи»

Что смог – показал. Про «доказать» — см. выше, про веру, смысл один и тот же.

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

Элементарно – вы скажете, что я графики от балды нарисовал. Даже не смогу доказать, что у нас кейс сработал. И какие бы цифры, отчеты, выписки со счета или из налоговой я не привел, вы сможете сказать – «пф, а причем тут кейс вообще?».

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

«Нет смысла, ничего не получится»

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

«Ерунда все это, детский сад какой-то, это не работает»

Вот это самое забавное, на мой взгляд. Кого вы пытаетесь убедить, что это не работает? Меня? Так у меня работает.

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

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

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

Я обязательно учту их в своей работе – мне важно знать о том, что вас беспокоит и в чем есть проблемы. «У нас совсем другая проблема – вот такая и вот такая»
Прекрасные и очень полезные комментарии.

«Автору надо посмотреть фильм/почитать книгу/поспать/помолчать/попрограммировать»

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

«Решать надо совсем другие проблемы, а не обозначенную»

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

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

Тут то же самое. Ну чего я объясняю, если вы – программист 1С, то вы только тем и занимаетесь, что приспосабливаете типовое, общее и универсальное к конкретным реалиям.

«Речь только о многократной продаже решений? В этом смысл?»

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

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

«Вообще не так надо работать, а вот так…»

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

«Это про проекты или про разовые работы?»

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

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

Только проект был сделан «плоским» — в виде перечня задач, разделенных некими вехами. Мы, кстати, именно на проектных работах проверяли в течение двух месяцев.

«Речь о выработке одного или нескольких программистов?»

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

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

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

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

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

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

«Зачем?»

Если вы – владелец бизнеса, то ответ, вроде, очевиден. Хотите роста – надо что-то менять.

Новые продукты, рынки, сервисы. В бизнесе 1С: Франчайзи, правда, можно ничего и не менять, потому что есть «мама», которая что-то сделает за вас. Тогда вы сможете расти, ничего не меняя – просто вслед за ростом рынка, сохраняя свою долю в нем.

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

Качество – это внутренняя характеристика, причем – конкретно вашего бизнеса. Если помните (я, почему-то, запомнил), была такая позиция у 1С: конкурируйте не ценой, а качеством. Качество вашей работы никак не зависит от «мамы» и конкурентов.

Производительность – один из показателей качества системы. Весь кейс – про производительность. Все, как «мама» велела.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть