Хотя, наверное, продавцов ёлок можно исключить из этого списка, они сумели меня удивить перед Новым Годом, продав мне настоящую ель. Раньше только пихты и сосны бывали. Я даже в интернете посмотрел, как отличить ёлку от пихты — реально, это была ель.
Так что в списке «Самые неразвивающиеся компаниии» остаются только франчайзи 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С: конкурируйте не ценой, а качеством. Качество – это внутренняя характеристика, причем – конкретно вашего бизнеса. Качество вашей работы никак не зависит от «мамы» и конкурентов.
Весь кейс – про производительность. Производительность – один из показателей качества системы. Все, как «мама» велела.
Комментарии (94)
DrPass
09.01.2019 23:18+1Хотя, наверное, продавцов ёлок можно исключить из этого списка, они сумели меня удивить перед Новым Годом, продав мне настоящую ель
На самом деле вам сделали только хуже. Сосна стоит раза в два дольше, чем ель, и пахнет приятнее :)
Scf
09.01.2019 23:18+2Т.е. изначально командной работы не было вообще (сеньоры держались за свою полезность и исключительность), а создавать команду предлагается стартапным способом (с сеньора знания, с джуна реализация, прибыль пополам).
Выглядит как переход из обычного провинциального болота в совсем нездоровую атмосферу.
Про типовые задачи и типовые решения — возможно, у вас специфика 1С, в других сферах либо мало типовых задач, либо типовые решения настолько сложны, что проще написать своё, чем изучать типовое.
exehoo
09.01.2019 23:38с сеньора знания, с джуна реализация
При этом обычно синьор на окладе у заказчика, а джуны набигают из Крупного Сетевого Франчайзи (тм),
прибыль пополам
половина джунам, половина всем остальным, включая поставщиков оборудования, пожарников и налоговую.
dimoff66
10.01.2019 09:30Про типовые задачи и типовые решения — возможно, у вас специфика 1С, в других сферах либо мало типовых задач, либо типовые решения настолько сложны, что проще написать своё, чем изучать типовое.
Все наоборот. В 1С разнообразие задач значительно больше чем в том же вэбе. В любом случае из вашего комментария неясно — если есть типовая задача и решения настолько сложны, что проще написать свое (хотя как это возможно, не понимаю, решение на то и решение, чтобы просто предоставить вам интерфейс), то что же мешает вам написать свою несложную?
aronovp
10.01.2019 00:36Если не секрет, как вы юридически оформляете возможность продавать клиентам больше часов, чем было реально затрачено?
gecube
10.01.2019 01:24Да какая разница, если клиенту в актах по факту можно написать сколько угодно часов (ес-но, в рамках разумного)? Клиент доволен, его задача решена, причем не дороже, чем по рынку.
Мне это напоминает какие-угодно суммы в тендерных документах в крупном Энтерпрайзе — главное, чтобы проект был сдан.aronovp
10.01.2019 20:16+3Мне почему-то кажется, что это может стать основой для уголовного дела по составу «мошенничество». Нужно очень аккуратно следить, чтобы формально количество проданных часов не превышало реальное время сотрудников + оплаченные переработки. Либо в договорах вводить понятие «нормочас» и иметь подписанный директором прейскурант услуг в нормочасах.
DrPass
11.01.2019 01:22Мне почему-то кажется, что это может стать основой для уголовного дела по составу «мошенничество»
Ну как может… теоретически — возможно. Практически — нет. Как что-то может стать основной для уголовного дела, если никаких прямых доказательств мошенничества не существует в принципе? Чтобы доказать мошенничество, нужны прямые улики, показывающие, что программисты сделали эту задачу за меньшее количество времени, чем указано в первичных документах. И где клиент, да хоть следователь с широкими полномочиями, их возьмёт?
Это одна сторона медали. Вторая сторона — именно так всю жизнь работает чуть ли не половина ИТ-компаний. Цифры в актах условные, нечто среднее между «сколько оно на глаз может занять времени» и «сколько можно вытрусить из клиента».
Причем у медали есть и третья сторона — и до ИТ было то же самое, да и сейчас продолжается в других отраслях. Возьмите какую-нибудь смету из живого контракта у строителей, металлургов, машиностроителей и т.д. Там вы увидите точные цифры, рассчитанные объемы работ — то, чего практически никогда не бывает у программистов. Обзавидоваться можно. Но не нужно. Потому что это на самом деле фонарь. Смет на самом деле две — одна контрактная, которая готовится под тендер и по которой потом формируются акты и получаются оплаты. Там написаны объемы работ согласно тендерной документации, а стоимость и всякие расходные материалы подогнаны, чтобы на бумаге получить их стандартную норму прибыли. А вторая для внутреннего пользования, реальная, с настоящими объемами/ценами работ и материалов. По ней исполнитель считает, сколько он на самом деле заработает.aronovp
11.01.2019 11:15В строительстве есть волшебные СНИП — если смета им соответствует — все просто шоколадно. Именно из них берутся точные цифры.
А вот в IT такого нет. И если вашему недовольному контрагенту (или конкуренту) очень захочется испортить вам жизнь, то достаточно написать заявление в полицию.
А при небрежном обращении с документами доказать достаточно легко:
Делается выемка документации.
По должностным инструкциям определяется количество работников, чьи услуги компания продает.
Считается количество часов оплаченных всеми заказчиками по всем договорам.
Из расчетных ведомостей или по данным НДФЛ определяется количество оплаченных разработчикам часов переработки.
Если количество проданных часов больше, чем рабочие часы + переработки, то можно дело в суд передавать.
Если же компания догадалась дополнительно оформить договор субподряда — повторить действие с субподрядной организацией.gecube
11.01.2019 11:23Это какие-то дикие российские реалии, когда налоговая может докопаться до любой цифирки в отчетности и актах/спецификациях etc. И никакого отношения к взаимоотношениям контрагентов это не имеет, кроме того, что они пытаются перестраховаться от подобных наездов. А вот выполнение работ (т.е. получение фактического цельного полезного результата) и фактическая оплата лежат в отдельной плоскости.
У меня строгое ощущение, что зарубежом возможно все сделать существенно проще. Выставляется счет на выполненные услуги, его подписывают оплачивают и все довольны.
Вопрос в конфликтных ситуациях, когда заказчик недоволен (но в этом случае все зависит от размеров каждого из контрагентов и подкованности юротделов, условно — чпшник против гугла скорее всего никаких шансов не имеет, но если компании одного порядка, то проще умаслить клиента)aronovp
11.01.2019 12:56+1Я честно говоря не знаю, насколько можно доверять художественным произведения, даже бывшего адвоката, но в романе Джона Гришэма «Фирма» именно за подобные фокусы ФБР «приняло» руководство юридической компании.
Тут важно, продаете ли вы по договору часы работы специалиста или какие-то абстрактные часы. В первом случае выставление большего количества часов это мошенничество, во втором нормальная коммерческая деятельность.
DrPass
11.01.2019 13:50+1Если количество проданных часов больше, чем рабочие часы + переработки, то можно дело в суд передавать.
Дело в том, что это не может служить доказательством мошенничества. Чтобы это прошло по уголовному делу, нужны конкретные факты — сколько часов и кем из сотрудников/субподрядчиков было потрачено времени на разработку каждого проекта из тех, что ведет компания. А может быть, это была не зафиксированная документально переработка? А может быть, это ненадлежащим образом оформленные трудовые отношения с внештатным специалистом?
Результатом подобной разборки с вероятностью 99% будут как раз претензии налоговой, вместе со штрафами. С вероятностью 1% ничего не будет из-за отсутствия прямых доказательств. Но никак не уголовка. В уголовном праве, в отличие от административного, действует презумпция невиновности. И пока есть хоть один теоретически возможный вариант, не связанный с криминалом, суд полагается именно на него.
А что касается административки, то накопать достаточно материала на штрафы можно в любой компании, независимо от вида бизнеса. Если уж пришли с проверкой, то что-то найдут обязательно. Не бывает таких компаний, у которых полный порядок с документами. Вопрос лишь в количестве бардака. У ИТшников, кстати, в бухгалтерии его обычно больше :)
VSOP_juDGe
10.01.2019 11:09Так делают не только мелкие 1с-франчайзи, но и крупные интеграторы. Например на тендере на сопровождение системы биллинга побеждают, предоставив самую низкую цену часа. А потом эти часы нещадно умножают вдвое и втрое.
Jef239
10.01.2019 03:39Гм, надо попробовать… Интересно, получится оно без табличек и графиков? Потому как мы не 1С и вообще «в Греции все иначе». Но общая идея вроде бы применима.
KTG
10.01.2019 06:01Насколько эффективно растут новые компетенции, если на их развитие ограничено время и что происходит в головах?
Суть вопроса в том, что «повышение эффективности» сводится к представлению сотрудника в виде робота, который не ест/не пьет/не моргает, а с головой его можно работать как с БД — что захотел то и записал/удалил.
Уровень растёт при решении новых задач, и не всегда первый подход влечет за собой верное решение. Но пока этот подход не завершён нельзя понять правилен ли он. Так вот, что если тому же новичку дать задачу, с которой он (условно) справится за 3 дня, набив десяток шишек но разобравшись с предметом. По описанной выше системе задачу у него заберут уже через 1 день. По мне вариант когда есть консультант на доле и подсказывает верный путь это решение. Но когда идёт просто передача задачи более опытному программисту, то у новичка остаётся каша в голове и след от неверного пути решения (при следующей аналогичной задаче он продолжит путь и опять потратит 1 лишний день в пустую). Новая задача и новые компетенции и ситуация повторится.
Можно предположить что новичок просто тупой. Только при приеме на работу от него требовались одни знания, с которыми он успешно справлялся (Чемпион в своей области), а сейчас есть желание его перепрофилировать или вменить дополнительные обязанности (новый продукт/технология), не отказываясь от навыков которыми он уже обладает. Т.е. сокращаем простой когда, к примеру, задач по его профилю нет.
DitriXNew
10.01.2019 06:02+2Долго думал — писать или нет. Но, таки решился.
Возьмем некую организацию «Х». В ней работает 50 человек, часть из которых программисты, часть — внедренцы, есть директор, есть уборщица и т.д. И все они влияют. Пришла уборщица — и выгнала на ветер весь отдел на 20 минут. 10 человек, по 20 минут, вот вам уже минус 3 часа в месяц :)
И попробуем применить ваши подходы…
Результатом будет — крах.
По пунктам:
1. Не бывает одинаковых задач, и одинаковых баз. Если мы не говорим за обновление бухгалтерии на новый релиз. И то…
И на этом я могу остановиться.
Возьмем самый банальный пример — загрузка товара из Excel. Что, что, а это есть у всех и всегда.
Я потратил 10 часов на написание обработки для клиента.
Теперь приходит второй клиент, у которого процессы совпадают на 99%. Но, у которого:
1. Сервер на старом железе
2. 10млн товаров, против 100тыщ.
3. Ошибки в доп свойствах (цвет, сезон, пол, и т.д., т.е. у него есть желтый, жолтый, жёлтый, жлтый и т.д.)
4. Макаки за компом, которым не нравится цвет кнопки в обработке.
5. Забытый маленький пункт, что товар может менять имя, или быть дубли кода/артикула
Все, вот вам +10 часов на каждый пункт. И шо?
Кроме этого — компетенция и опыт — это интуиция.
Вот что отделяет профи от зелени. Только интуиция. И все. Как вы этим будете торговать между сотрудниками? А чтобы тот профи мог подсказать — ему надо вникнуть в задачу. И даже если он вникнет, и скажет потом новичку — иди к клиенту и скажи, чтобы они переделали желтый цвет в один, то что вынесет жуниор? Что надо смотреть на цвет? :)
Основная проблема 1С программистов в том, что они не программисты, а хрен знает кто. Ибо они общаются на прямую с клиентом, и паника клиента передается им. И настроение клиента — тоже им. Возьмите С++ программистов, возьмите проект на 500к$ на 2 года, и скажите — сколько программистов С++ будет общаться с клиентом? НОЛЬ! А сколько программистов 1С НЕ будет общаться с клиентом? НОЛЬ! Все там будут.supersmeh
10.01.2019 09:33Моё мнение такое.
Про загрузку из Excel как раз хороший пример. Пример того, что в первый раз сразу надо было делать «универсальный» загрузчик, который предусматривает, по возможности, самые распространенные косяки в исходных данных. В Вашем же примере — берете решение, написанное для первого заказчика, и дорабатываете его до «универсального», предусматривающего все нюансы второго. Третьему заказчику, с большой долей вероятности, уже можно будет продать загрузчик почти без изменений.
Программисты 1С общаются с клиентами не по своей воле, а из-за того что так «криво» устроен этот бизнес. Никто не мешает нанять «аналитиков», которые будут общаться с клиентами и выдавать задания программистам. Но мало кто это делает потому что это доп.затраты, «а нам они нужны? вон пусть программист сам выясняет у клиента чего там надо сделать». Т.к. правильно в статье написано — надо урвать здесь и сейчас.peresada
10.01.2019 10:28Про загрузку из Excel как раз хороший пример. Пример того, что в первый раз сразу надо было делать «универсальный» загрузчик, который предусматривает, по возможности, самые распространенные косяки в исходных данных. В Вашем же примере — берете решение, написанное для первого заказчика, и дорабатываете его до «универсального», предусматривающего все нюансы второго. Третьему заказчику, с большой долей вероятности, уже можно будет продать загрузчик почти без изменений.
1 задача: тратите 10 часов
2 задача: тратите 50 часов, дорабатывая 1ую задачу до универсальности
3 задача: тратите 5 часов, дорабатывая 1ую задачу для интеграции
…
10 задача: тратите 150 часов, чтобы исправить излишнюю сложность из-за универсальности
…
99 задача: программа все еще не универсальна, безумна сложна, на которую потрачено 100500 часов, в которой разбираетесь только вы
VSOP_juDGe
10.01.2019 11:11Сколько не видел универсальных загрузок, всегда было проще написать специфическую, чем пользоваться универсальной.
Hardcoin
10.01.2019 12:30сразу надо было делать «универсальный» загрузчик
Тьюринг-полный? Если нет, то он не универсальный, обязательно где-то что-то вылезет. Написание "универсального" решения для таких задач — это время, полностью выкинутое в мусорку. Но понимают это обычно на практике. Каждый программист в своей карьере пробовал делать что-то "универсальное".
Dementor
11.01.2019 16:07Согласен. По времени быстрее сделать болванку на базе первого проекта, а далее подгонять ее под каждого нового клиента с его спецификой, чем пытаться писать «универсальный» инструмент на все случаи жизни.
DitriXNew
11.01.2019 02:04Про универсальность ответили ниже. Ибо, что такое универсальность?
Надо учесть:
1. Версии 1С
2. Конфигурации, версии конфигураций, доработки в конфигурациях и т.д.
3. Версии винды и установленные на них версии экселей
…
Короче — не реально.
На счет второго — а вы так пробовали делать?
Понимаете, если вы хотите набрать таких аналитиков, то вы раздуваете штат, это раз.
Два — у аналитика должна быть ЗП не ниже программиста, ибо со знаниями, на базе которых он может нормально ставить задачи — любой нормальный аналитик пойдет в программисты или внедренцы. Но тогда программисты и внедренцы будут паниковать.
Три — вы раздуваете неимоверно штат, где нужен минимум 1 аналитик на 2 программиста, плюс минус. Т.е. при штате в 20 программистов — вам надо минимум 5 аналитиков, это не считая внедренцев.
Вам надо где то этих аналитиков найти, и обучить, а с учетом того, что в 1С есть такие классы как — программист, внедренец, техподдержка и тыжпрограммист. То как бы все. Приехали. Нет курсов для аналитиков.
Я к чему все это — вы пошли ложным путем. До вас уже все было придумано в стартапах.
Где есть такое понятие, как пайпакеты, которые перераспределяются раз в год, и все.
И при перераспредлении есть балы, которые начисляются за всякие плюшки, где, кстати, максимально бал дается именно за обучение нового сотрудника. Тогда, тот кто обучал — получает еще +2%, например, при том, что остальные тоже же иногда подсказывают, но они не получают за это +% некий, так как новый сотрудник = больше работы = больше денег = от их существующего процента они получат больше.
Тогда решены все проблемы, а их много глубже:
1. Вася сдал проект. Вася облажался. Вася зарывается. Всем похрен, ибо Вася только гребет деньги с этого проекта, а я пойду спать.
Имея пай — мне уже не похер. Да, Вася налажал, но, если клиент уйдет — это ударит по моим деньгам напрямую.
2. Я стараюсь делать задачи быстро, и, если какой то не хороший человек сидит рядом и смторит канальчик на ютубе — я могу сам подойти и спросить — а че ты мои деньги профукиваешь? Т.е. я работаю, ты с меня процент получишь, а я с тебя — нет? Эээ не друг, так не пойдет.
Т.е. сами сотрудники внутри сидят и строят надзор. В том числе и за качеством, ибо клиент уйдет — я получу меньше.
Ну и куча всего остального.
А теперь барабанная дробь…
Итого — проблема в том, что сам директор, обычно — делиться не хочет. Он хочет урвать максимум, зафигарить кое как проект, снять сливки, потом потеряться от клиента.
Он не хочет, чтобы сотрудники получали больше, ибо это значит надо перед ними отчитываться о доходах. И вот тут кстати, самый ржач, ибо обмануть 1ссника, который имет фул доступы ко всем базам клиентов, где он видит сколько реально платят его фирме — то тут нагнуть не выйдет. И все в таком же духе.
Так что не мудрите никуда. Все много проще. А главная особенность пая в том, что вы его получаете только пока работаете тут, а значит, уйти в другое место — уже тупо не выгодно. Ну вообще никак не выгодно. А компания при этом не боится терять компетенции.
VMAtm
10.01.2019 21:22Небольшая добавка, про интуицию. Есть такая книга, «Источник силы: Как люди принимают решения», английское название Sources of Power: How People Make Decisions. Там очень подробно объясняется то, что стоит за интуицией. Её тоже можно развить.
ShakalJack
10.01.2019 06:02Спасибо автору, интересная статья. Хоть я и не программист, а будущий бухгалтер, основной принцип кейса понял и воспылал желанием как-нибудь, если в будущем буду иметь бизнес, его опробовать. Жаль только, что в статье все было конкретизировано на програмистскую тематику.
Возникла просьба, не мог бы автор дать ссылки на источники, коими он вдохновлялся при реализации этой системы, или которые могли бы более обширно описать те «другие» упомянутые методы оптимизации работы?
dimoff66
10.01.2019 06:39+11. Подход с типизированием решенных задач безусловно верный и экспоненциально может увеличить прибыль компании. Я бы добавил сюда, что ограничиваться рамками компании не стоит, нужно также перенимать опыт других — огромное количество решений бесплатно или за копейки есть на инфостарте, все это подлежит изучению и переиспользованию.
2. С вопросом передачи компетенций автор статьи сильно усложнил. В век форумов о каких компетенциях речь? В любой момент вы можете воспользоваться коллективным разумом, а уж эффективность использования этого разума в конкретных проектах зависит только от опыта и личных качеств сотрудников. Это не передается.
3. По поводу
Просто и банально. Дежурный, которого мы обсуждали в прошлой статье, каждое утро собирает всех программистов в кучу, и они дружно смотрят на новые задачи.
Надеюсь эта скрамная тупость никогда не войдет в мир 1С, на новые задачи будет смотреть старший программист(как приятно пользоваться русскими словами вместо вонючего тимлид) и решать из своего опыта, а программисты будут тратить свои драгоценные часы на что-то более интересное, чем написание чисел на бумажках. Пожалуйста, не лезьте со своим идиотским скрамом в мир 1С-франчайзи, там и так проблем хватает.
DoctorMoriarty
10.01.2019 10:19>В век форумов о каких компетенциях речь?
О настоящих, профессиональных компетенциях, а не об умении быстро нагуглить результат.
>старший программист (как приятно пользоваться русскими словами вместо вонючего тимлид)
Ага. И «ЭВМ» вместо этого треклятого «компьютер». Прямо как французы со своим «ordinateur». Только вот момент, «программист» — происходит от «программа» с добавлением суффикса «ист»:
от др.-греч. ????????? «публикация, объявление, приказ», от гл. ?????????? (????????) «писать впереди; писать раньше; объявлять, предписывать»; из ??? «впереди, перед» + ????? «пишу».
и
от франц. -iste от лат. -ista, далее от др.-греч. -????? и др.-греч. -????? (-ize) из агентивного суффикса -???. Родственен суффиксу -??µ?? (-ism)
Упс. Ни одного русского источника, вот же незадача…
Кстати, называть слово вонючим только потому, что оно имеет происхождение из неродного для вас языка — это, батенька, вонючий шовинизм. Так-то.
И, кстати, тимлид совершенно не обязательно старший программист. Я близко знал несколько проектов, где тимлидом у программистов был системный аналитик. И не потому, что не нашлось старшего программиста, разумеется.
Hardcoin
10.01.2019 12:43старший программист(как приятно пользоваться русскими словами
Это для вас "программист" — русское слово. Для ваших родителей — не русское. Для ваших детей и "тимлид" будет русским.
dimoff66
10.01.2019 13:34Моя мама работала еще в 70-х годах инженером-программистом, тогда эта профессия возникла и так она и называлась.
DrPass
10.01.2019 19:42Да, а лет за триста до вашей мамы тогдашние борцы за чистый Великорусскiй Языкъ возмущались против использования в нём поганого иностранного слова «инженер» (и не менее поганого слова «профессiя»), а их потомки при вашей бабушке возмущались против использования поганого иностранного слова «программист».
saboteur_kiev
11.01.2019 02:15+1В СССР инженеров-программистов практически не существовало.
Для начала не было таких учебных заведений, которые бы выпускали программистов.
Да и позиции были больше оператор ЭВМ, а инженер-программист это скорее должность в каком-нить НИИ
kinall
10.01.2019 11:28Чем вот это:
Исполнитель подходит к «знающему», предлагает сотрудничество. «Знающий» говорит – там делов на пару часов, у меня и пример есть, надо немного доточить, и все. Сколько хочешь? – спрашивает исполнитель. Ну, давай 40 % — говорит «знающий».
отличается от вот этого:
Ну отдал ты человеку свою обработку или подсистему, он закрыл за день оговоренные с клиентом 40 часов, поднял 20 т.р. Тебе что с этого? Можно, конечно, договориться, и породить черный рынок внутри отдела, но смысла нет.
?KTG
11.01.2019 04:13ИМХО.
Как минимум прозрачностью положения дел и компетенций.
Да и во втором случае идет явное перебрасывание задачи без прокачки «новичка» и без заинтересованности прокачать его, не отнимая у него полностью хлеб.
Ну и разумеется степень вовлечённости.
stanislavkulikov
10.01.2019 11:49Объясните пожалуйста одну простую вещь(это не сарказм, я действительно не понимаю): я могу допустить, что мир 1С сильно отличается от всей другой разработки, но не так же кардинально. В том же Питере/Москве есть софтверные компании с похожими принципами (тот же EPAM сразу приходит на ум), где продают либо часы разработчиков, либо готовые решения под ключ. Но вот почему-то нигде нет таких проблем, что разработчик знает только одну маленькую область и не хочет учится чему-то новому. Ну т.е. всегда есть те, кому лень учится, но они получают маленькую зарплату и либо смиряются с этим, либо начинают учится. И что значит
Можно заставить Чемпиона даже семинар, или обучение провести. Он честно отчитает материал – тот, который итак доступен в интернете. Реальные, практические знания он все равно оставит при себе.
Это что, такие тайные знания, которые передаются из уст в уста? Почему в других сферах спокойно можно научится чему угодно, почитав мануалы из интернета и только в 1С нужна какая-то специальная передача знаний?
В общем не очень понятна сама суть проблемы и почему стандартная мотивация уровнем зарплаты не работает.Deq56
10.01.2019 12:35Ну может, из за предметной области, 1с ЗУП, 1с БУ, 1с Документооборот, 1с УТ, 1с etc это разные вещи где нужно знать предметную область, сами конфигурации, особенности конфигураций. И в связи с этим, проблематично изучить это всё.
gennayo
10.01.2019 12:45У 1С-ников во франчах в основном почасовая сделка, им некогда новое изучать, часы закрывать надо.
stanislavkulikov
10.01.2019 12:54Так вот может в этом то и проблема? Может стоит тогда попробовать систему с фиксированным окладом по грейдам?
gennayo
10.01.2019 13:04Да, собственно, сейчас тенденция именно такова. Только вот не подходит она для мелких франчей на 4-5 разработчиков, ели они не «сидят» на каком-нибудь «жирном» заказчике.
biilsun
10.01.2019 18:37Помимо кодинга в 1С необходимо знать предметную область, бухгалтерский учет, налоговый, управленческий, производство, планирование производства, логистику, МСФО список можно долго продолжать, всё знать, изучить и поддерживать эти знания невозможно. Клиент на блюдечке не принесёт и не скажет хочу так-то и так-то из него нужно клещами тянуть зачастую он сам не знает, как должно быть приходится самому предлагать варианты.
paranoya_prod
10.01.2019 17:28Пока читал, думал о том, возможно ли натянуть это одеяло не на разработку, а на сервисный ИТ-бизнес? И продажников с маркетингом им же укрыть. Потому как знания важны и нужны в разных областях. А бизнесу необходимо эти знания сохранять и приумножать.
В общем — надо продумать детали и попробовать.VMAtm
10.01.2019 21:26Мне кажется, основной посыл автора — как при улучшении производительности системы — замерить показатели и улучшить там, где хуже всего. У автора это было в отношении дележа знаний и мотивации, в вашей команде может быть где-то ещё.
Skynet2034
10.01.2019 17:49+1«Знающий» сработал по 1600 рублей в час (потратил 15 минут, получил 400 рублей). Ну, на то он и знающий. Обычные работы, т.е. свой труд и свое время, он продает по 500 рублей в час, а свои реальные знания – по 1600 рублей в час.
Здесь есть одна проблема. Свои реальные знания «продать по 1600 рублей в час» — получится только один раз. Т.к. в следующий раз тот человек, которому ты эти знания продал — к тебе по этому вопросу обращаться уже не станет (если он конечно амнезией не страдает). Более того — он эти знания всем остальным продавать начнет, ну скажем, по 1200 руб/час.
Так что получается почти та же история, что и при обычной сдельной оплате — также выращиваешь себе конкурента, но получаешь за это однократный платеж.
При таком раскладе для «чемпиона», который забирает себе бОльшую часть всех работ — экономического смысла делиться компетенциями по прежнему не будет.
andi123
10.01.2019 18:17А можно комментарий по поводу разработку новой неведомой фигни?
Это все очень замечательно, когда приходится решать много однотипных задач.
А когда приходится каждый раз решать множество новых задач (это всякие НИ и ОК Р).
Я согласен, что всегда есть типовая обвязка которую можно взять готовую (но это только часть работы). А когда вся суть работы сводится к изучению, исследованию и выдаче некого макета решения и именно это будет результатом. И заранее вообще ничего не известно, что там будет и как.
kagarich
10.01.2019 18:37Возможно для 1С это и нужно (я совсем не знаком с этой экосистемой), но для «обычной» разработки, как мне кажется, все это избыточно. В типовом цикле разработки задачи редко разбиваются на атомарные (равные или меньше 1 дня) и еще реже бывает постоянный входящий поток меняющихся задач, которые надо оперативно (=ежедневно) распределять между исполнителями (это больше напоминает сервис-деск, где вместо запросов на обслуживание постоянный поток запросов на разработку).
А вот в том самом «типовом» цикле разработки, как по мне, так более логична система «потогонки», построенной по следующему принципу:
— есть список задач оцененный архитектором (или иным экспертом высшего уровня) с точки зрения трудоемкости;
— есть коллектив разработчиков, разной квалификации и компетенций;
— есть тимлид, который распределяет задачи между разработчиками, соблюдая принцип, что уровень макси.утилизации не выше 70% (это для примера);
— в итоге есть задачи стоящие в очереди, т.к. разработчики максимально утилизированы (на те самые 70%);
— если разработчик успешно закрывает назначенные на него задачи — получает свой фикс обозначенный в оффере;
— если разработчик хочет получать больше фикса, то он идет на «биржу» где в онлайне список нераспределенных задач, с оценками их трудоемкости в часах; разработчик может быть не согласен с оценкой трудоемкости, но это его проблема; на бирже реализован принцип обратного аукциона, т.е. в конце каждого дня проводятся торги, где все заинтересованные разработчики ставят свою оценку того кол-ва часов за которое решат эту задачу, эта оценка не может быть выше назначенной архитектором, только ниже; любой разработчик может перебить оценку другого разработчика выставив свою оценку, которая ниже уже данной; таким образом, разработчик может набрать себе задач на 80, 90, 100, 150% утилизации, и получить вознаграждение в определенной прогрессии — чем больше ты себя утилизируешь, тем выше стоит твой час;
— как следствие — вопрос твоей компетенции, вопрос реального кол-ва потраченных на задачу часов, вопрос твоей низкой, или наоборот сверх-высокой утилизации — это личный вопрос конкретного разработчика — он сам себе рулит своей загрузкой в определенных пределах, он сам себе рулит своим набором компетенций.
Там много разных тонкостей, если кому-то инетересно, могу подробнее написать.
Teratsov
10.01.2019 18:37Из всего предложенного космическим показалась тема с автоматизацией учета компетенций, необходимых для решения задачи. Понятно, что при выборе исполнителя это в том или ином виде учитывается, но чтобы при постановке задачи в таскменеджер постановщик указывал список компетенций… У нас не взлетело, хотя попытка была. Справочник компетенций оказался не маленьким, не каждый постановщик понимает, какая компетенция для чего нужна, трудов все это добавляет, профит где-то далеко за горами… Короче, постановщики забили.
Наверно, это может заработать в масштабе одной команды, когда постановщик один, и он же выгодополучатель, как в примере автора. Как масштабировать на разные команды с разными постановщиками — менее понятно.
Тема с управлением и учетом взаимопомощью — огонь! Тут и сам эффект наличия наставника, который поможет, и понимание загрузки «знающих». Среди знающих, периодически, встречаются такие индивиды, на которых «не знающие» просто ездят. И без учета этой езды иногда просто недоумеваешь, когда пытаешься понять, чем занимался «знающий» последние пару дней.
Остальные описываемые действия понятны, плюс/минус так и происходит, польза очевидна.
gennayo
10.01.2019 20:04Кстати, вот другое направление развития 1C (и франчей в частности) — технологическое infostart.ru/public/969637
wmgeek
10.01.2019 20:11Мне кажется стабильной работа за зарплату.
Чемпион получает чемпионский оклад. Джун — джунский. Остальные посередине.
Все начиная со старшего спеца получают бонус по результатам работы компании.
Чемпиону выгодно тренировать спецов, так как улучшается результат компании и его бонус.
Джунам выгодно расти до спецов, тоже бонус хочется.
Я делюсь опытом не потому что мне выгодное его продавать здесь и сейчас. Я делюсь опытом, потому что обучая других сам познаю мастерство еще выше. Что стоят твои знание если о них никто не знает? Метрики — это хорошо. Но свобода — лучше.
DmitryBurykin
11.01.2019 07:42«Что стоят твои знание если о них никто не знает»
Может твое знание стоит столько за сколько его можно продать?wmgeek
11.01.2019 15:48Все мои знания стоят мой оклад. То, что результат моего труда сегодня продан за 1, завтра за 10, а после завтра за 100 не изменит цены знания. И не заберет знание у меня.
pahmutov
11.01.2019 07:42+1В целом впечатление от статьи такое: в самом начале «автор, wtf?», дальше «а вот уже что-то разумное», в конце «а ну такая себе вполне здравая идея». Хотя есть и существенные замечания.
Но пройдусь по деталям.
Во-первых, про
Они думают только о сегодняшнем дне. Возможно, виновата жесткая привязка к одному вендору, который разрабатывает и фреймворк, и прикладные решения. Никто же в здравом уме не будет в 21 веке строить долгосрочный бизнес, завязанный на один язык программирования, одну среду разработки, один рынок?
Специфика 1с как раз в том, что именно завязано на один язык программирования-среду-рынок. Потому что это фактически монополист автоматизации бух. и разного другого учета. Потому что только 1с своевременно обновляет все эти стопиццот тыщ строк кода учета льгот, новых форм отчетности и постоянной, ужасающей своими объемами, сменой налогового и бухгалтерского законодательства. В других странах отлично работает динамикс, САП (для них она не так дорога, как для российского рынка) и прочие программы, которые не нужно обновлять каждый месяц. У нас – нужно. Поэтому такая конъюнктура создает такое особое программирование – 1с. И так будет продолжаться дальше.
Далее:
Во-вторых, люди приходят и уходят. Одного разовьете, он переедет в Москву, придется брать другого.
Вот, в этом ключевая проблема франчей. Каждый уважающий себя программист 1с, как только достигнет определенного уровня компетенций, будучи младшим программистом франча, увольняется из франча. И чаще всего идет штатным программистом 1с к одному из своих клиентов на оклад. Выгодно это всем: программисту, потому что он сидит ровно на одном месте, не переживает за выработку часов и может тупить в интернетике на рабочем месте. И к тому же, зарплата на руки может оказаться выше. Клиенту, потому что франчу он платил по 2000 руб/час, а штатнику будет платить оклад, допустим 40 тысяч в месяц (возьмем регионы). Задачи будут решаться в том же объеме (ведь программист уже вумный и в курсе конфигурации клиента), а платить надо меньше.
А очень невыгодно это франчу. Потому что руководители проектов (они же тимлиды или, как озвучили в каментах «старшие программисты») потратили свое время и усилия для обучения младших зеленых новичков после универа, а через годик к ним приходят снова такие же. И учи их заново. Сам таким был)
Потому по моим ощущениям, качество обслуживания клиента франчом получается ниже, чем штатным 1с-ником. Просто потому, что штатный – это уже более-менее матерый 1сник. Потому что через 3-4 месяца работы он знает специфику. А франчи могут сегодня одного младшего послать, а завтра другого. И все они тупят. Ой, т.е. прокрастинируют.
Идем далее:
Программист 1С – особый человек, с сильно выраженной диалектикой в оценке своего места в мире. С одной стороны, он понимает, что приносит пользу этому миру. С другой стороны, он переживает, что он – не настоящий программист, получает большие деньги зря и, вообще, он – кто-то вроде «приживалы», подсевшего на временную, но прибыльную тему. Отчего программиста 1С не покидает ощущение, что все это когда-нибудь закончится.
Ну вот какой-то странный комплекс неполноценности у автора. Я 1с-ник с 2004 года (примерно). И вполне доволен и считаю свою работу стабильной, знания полезными и нужными. Когда при мне СИшники или вебдевы снисходительно усмехаются при фразе «1с-программист», я так же снисходительно усмехаюсь в ответ.
А вот это жиза, да:
Иногда такой процесс напоминает разведку боем: программист не только читает заголовок задачи и детальное описание, но и комментарии, а потом – лезет в конфигуратор, чтобы понять контекст. Посмотрит, потыкается – фу, скажет, это задача про спецодежду, там черт ногу сломит, в этой УПП. Не, пусть Колян делает. Минут 15 потеряно. Умножаем на 10-20, сколько получится? До 5 часов?
Это ладно, если программист толковый, и ему достаточно контекста для принятия решения. А он, допустим, большой любитель интернета, и пошел искать готовое решение – на том же Инфостарте, или партнерской конференции, или еще где. Время выбора начинает расти с устрашающей скоростью.
А вот еще интересное место:
Если вооружиться таким подходом, то потребуется совсем немного – писать абстрактные настраиваемые инструменты (вместо контекстного, сиюминутного говнокода) и где-то их хранить. Первое мы обсуждали, второе имеет массу вариантов решения.
Это не работает в реальной жизни 1с-ников. Потому что у них аврал. Дедлайны. Злой клиент, который хочет и требует задачу быстрее. Нельзя озвучить клиенту задачу создания загрузки номенклатуры из эксель на 48 часов. А именно столько займет написание абстрактного настраиваемого инструмента. Клиент переварит только часов 8. За это время можно сваять говнокод. Да, следующему клиенту с аналогичной задачей можно за следующие 8 часов допиливать до некоторого универсализма обработку от первого клиента и так, к 3-4 клиенту у нас будет готовая, универсальная. А 4 клиент возьмет и скажет: у вас тут сложный очень интерфейс, мы такого не заказывали, чтобы столько настроек при загрузке делать. Вот зачем у вас тут поле с характеристикой номенклатуры, мы их не используем вообще, зачем вы это сделали? Нам мешается оно, 30 полей настройки заполнять перед загрузкой. И нужно чистить эту универсальную обработку от лишнего.
Есть еще вариант купить/скачать на инфостарте готовую более-менее универсальную обработку, включить ее себе в багаж знаний, а клиенту эту инфостартовскую обработку за 4-5 часов доработать под его требования. И взять с клиента 8 часов.
А вот это очень тру:
Основная проблема 1С программистов в том, что они не программисты, а хрен знает кто. Ибо они общаются на прямую с клиентом, и паника клиента передается им. И настроение клиента — тоже им. Возьмите С++ программистов, возьмите проект на 500к$ на 2 года, и скажите — сколько программистов С++ будет общаться с клиентом? НОЛЬ! А сколько программистов 1С НЕ будет общаться с клиентом? НОЛЬ! Все там будут.
Вот это прям реальная самая главная проблема 1с-программистов, неважно штатники они, или сотрудники франчей. Как решать проблему оптимизации, если куча времени уходит на совещания, согласования и переделку ТЗ, битвы с заказчиком, что он хочет сделать нереализуемый неработающий бред? А сколько времени уходит на изучение бизнес-процессов. Которые уникальны для каждой организации. Вот основная проблема. Но этот кейс в статье с этой проблемой никак не поможет. По моему ощущению и не практикующие программирование «менеджеры по работе с заказчиком» не помогут. Хоть как-то решить это сможет ОченьСтаршийПрограммист с огромным опытом, с наличием в голове множества компетенций и готовностью быстро генерировать будущую архитектуру решения прямо в процессе обсуждения задачи с заказчиком, да еще и умеющего убедить заказчика, что именно вот так будет заказчику правильно и классно. А такой программист стоит дорого.
Программисты 1С общаются с клиентами не по своей воле, а из-за того что так «криво» устроен этот бизнес. Никто не мешает нанять «аналитиков», которые будут общаться с клиентами и выдавать задания программистам. Но мало кто это делает потому что это доп.затраты, «а нам они нужны? вон пусть программист сам выясняет у клиента чего там надо сделать».
o4evidec
11.01.2019 07:42+1Прочитал первые абзацы показалось интересно (так как только начал работать программистом..) далее дойдя до мотивации понял, что если это бы был диалог мне пытаются по.ссать в уши.
До этого работая федеральной конторе порядка 11 лет понял что единственная мотивации выгодная сотруднику и владельцу это прямая зависимость зарплаты сотрудника от дохода компании.т.е. не каких окладов. Люди старого склада ума могут возразить мол как считать зарплату уборщицы или того же руководителя отдела не связанного напрямую например с продажами услуг, товаров… как же безопасность, коммерческая тайна и т д. А люди не лишённой логики и аналитическим складом ума без проблем смогут организовать такие связи и зависимости их труда от доходов организации. Очевидно, что при таком решении останется следующая цепочка из трёх элементов. Владелец — разработчик бизнес и иных процессов необходимх для жизни организации — исполнитель. По очевидным причинам переход на такой принцип работы, простой и логичной схемы работы будет не скоро или не когда так как на большинстве организаций. Т.к. от паразитов в системе труда избавиться вряд-ли получится. Такую прямую схему работы можно увидеть в такси, фрилансеры и т.п. работающие за конкретный результат. Наверняка у большинства был коллега который работал меньше вашего а получал не соизмеримо своему труду. Такие же паразиты придумали платить за работу по времени, 1500-2500р в час за какую то работу,… а не за конкретный результат…gennayo
11.01.2019 08:07А если дохода у компании вдруг нет — работники не должны получить зарплату?
o4evidec
11.01.2019 10:25на сколько я вижу ситуацию очевидно что нет. ведь у каждого работника мотивация есть.
если продажи не идут и дохода нет виноваты все.
Или Вы считаете что луче платить со своего кармана работникам за отсутствие у них способностей улучшить ситуацию для получения дохода?
У владельца организации которые предлагает исполнителю работу по договору есть обязанность платить ему? и вообще зачем держать предприятие если доходности нет… вот если это временно можно взять в долг (кредит и прочее ) и платить исполнителю иначе закрыть конторку…
Ведь Владелец должен позаботься о доходе раз обязался платить, использовать инструменты по окупаемости работы, бизнес кейсы и прочее…
KTG
11.01.2019 08:59А люди не лишённой логики и аналитическим складом ума без проблем смогут организовать такие связи и зависимости их труда от доходов организации.
Ну раз обладаешь такими качествами, то может подскажешь как всё таки связать зарплату уборщицы с продажами в магазине? И как собственно она может повлиять на свою зарплату, что бы заработать больше? Если не воспринимать подобный изречение всерьез, то видимо она может гонять ссаной тряпкой менеджеров что бы продавали лучше…
Суть в том, что у уборщицы фиксированный объем работ — площадь помещения и количество уборок в день. Ей неважно натоптали сегодня посетители, продали ли хотя бы 2 утюга и 3 телевизора и уж точно плевать сколько предприятие заработало за сегодня 1 рубль или 2.o4evidec
11.01.2019 09:28вот вот… Ей плевать… мотивации нет.
по фантазируйте на тему того как уборщица влияла бы на улучшение продаж? утюгов и т.д.
Для компании — чистота помещений, улыбки клиентам, в рамках разумного привлекательный внешний вид, отзывчивость в рамках своих полномочий.
Для Исполнителя — предложение доп. услуг в рамках своих способностей, при наличии свободного времени поиск доп работы в шаговой доступности.
Просто? а так оно и есть это уже давно работает только народ все равно страдает.
Почему уборщится которая работает на предприятии 10 лет и старается каждый день не получает процент от дохода если доход предприятия вырос в два раза за последний год?
будет она еще больше стараться? или владельцу проще ее выкинуть и нанять за меньшие деньги?
Далее пример. доход это 100% (пирога) он к примеру варьирует в пределах месяца 10%
за вычетом накладных расходов получаем к примеру доход 50% далее делим пирог. с учетом минимальной оплаты труда и рыночной цены услуг сотрудника.
В целом идея заключалась в том что бы для исполнителей была эл. площадка где две стороны могли договорится. эл. площадка — действующий аналог torgi.gov.ru но для людей его не сделали только для юриков.DrPass
11.01.2019 14:10+2вот вот… Ей плевать… мотивации нет.
У уборщицы как раз очень хорошая мотивация, т.к. результат её работы на виду. Помещения чистые — всё ок, говорят «спасибо» и платят зарплату. Помещения убираются плохо, получает люлей от начальства, а при систематическом повторении увольняется.
А подвязывать оплату её труда к доходам компании — это трэш. К доходам компании должны быть подвязаны оплаты только тех сотрудников, которые на эти доходы влияют непосредственно, т.е. топ-менеджеры. Рядовой персонал отлично будет сопереживать за компанию и в том случае, если просто после коммерчески удачного года получит приятную премию, а в процессе работы компания будет нормально к нему относиться и не жлобиться по поводу мелочей.
Почему уборщится которая работает на предприятии 10 лет и старается каждый день не получает процент от дохода если доход предприятия вырос в два раза за последний год?
Вам не кажется, что 10 лет кряду мыть одни и те же полы — не совсем достаточное обоснование, чтобы автоматически начать получать дивиденды от чьего-то бизнеса?o4evidec
11.01.2019 15:34По вашему чистые полы не влияют на качество работы сотрудников т.е. не будет разницы если сотрудники будут в свинарнике или в чистом помещении и это не будет влиять на их здоровье на впечатление клиентов?
В среде военных структур такое называют выслуга, только там деньги бюджетные.
Собственно поэтому бытует фраза бедные беднеют а богатые богатают.
На мой взгляд это привычка взглядов на работу.
Собственник так и посчитает что если я тут придумал как заработать денег «зачем мне платить проценты от дохода уборщице ведь она просто моет полы а я думаю»…DrPass
11.01.2019 16:20По вашему чистые полы не влияют на качество работы сотрудников т.е. не будет разницы если сотрудники будут в свинарнике или в чистом помещении и это не будет влиять на их здоровье на впечатление клиентов?
Я не знаю, какими хитрыми умозаключениями вы пришли к такому выводу из моего комментария, но нет. Там написано именно то, что написано, и надо воспринимать это буквально.
Содержать полы в чистоте — это прямая должностная обязанность уборщицы. А водителя троллейбуса — вести троллейбус. А кассира — проводить денежные расчёты. И если человек не выполняет свои прямые должностные обязанности, то ломать голову, как же ещё замотивировать его, бедненького, чтобы он начал работать, а не просто ковырял в носу за деньги, это уже ненормально. Зарплата — его мотивация. Если человек не хочет выполнять те условия, под которые он сам же подписался при заключении договора, зачем тогда он вообще тут работает?
В среде военных структур такое называют выслуга, только там деньги бюджетные.
Да, и это не процент от годового бюджета армии, а всего лишь некоторая надбавка к зарплате :)
Собственник так и посчитает что если я тут придумал как заработать денег «зачем мне платить проценты от дохода уборщице ведь она просто моет полы а я думаю»
Ну да. А что не так? Есть рыночная цена услуг по уборке, есть личные деньги собственника.
Вас же, покупая десять лет подряд печеньки в одном и том же магазине, не посещала мысль предложить магазину платить за печеньки на 50% больше, чем указано в ценнике, потому что и вы с ними давно сотрудничаете, и доход ваш с тех пор поднялся, верно?o4evidec
11.01.2019 16:37Личные деньги собственнике обеспечены кем? Уборщица вообще по вашему не участвует? То есть она просто как необходимость как принтер без которых нельзя напечатать документ для отчётности?
Люди воюют потому что делят и делят других на категории религии и т.д. вы попробуй те оценит любого сотрудника как именно того кто влияет на прибыль — партнера, а не как раба.
Большая часть работает потому что тупо выбрать не из чего. Везде для его уровня спообности дают те же минимальные деньги чтобы выживать.
По поводу печенья. Если вы берете в одном месте долгое время то либо поднимут цены либо снизят качестве это уже просто статистический факт. Т.е. вы платите в любом случае больше не зависеть от вашего дохода. А если ещё по стране зарплату поднимут то печенья обязательно подражают… так и происходит по факту…Zenitchik
11.01.2019 17:17Вы упускаете из виду, что у уборщицы функция её влияния её на доход имеет плато, и в норме качество работы уборщицы на этом плато и находится. Т.е. если она будет работать хуже нормы — это быстро скажется на доходе, но если она будет работать лучше нормы — это на доходе не скажется никак.
Допустим, уборщица будет иметь долю от общей прибыли, и, соответственно, нести долю от общих рисков. С учётом особенностей функции её влияния на доход, для неё эта прибыль и риски будут лотереей: когда она выходит на плато, доходы компании начинают зависеть в основном не от неё.
Иными словам, если уборщица работает плохо — она теряет в деньгах, это понятно, это объяснимо, но если она работает хорошо и ещё лучше — она толи выигрывает в деньга, толи не выигрывает — в зависимости от остальных участников. Вы бы согласились работать в таких условиях?o4evidec
11.01.2019 17:22Да, так как Это и есть мотивация. Все в одной лодке. Все зависят от друг друга как следствие понимание, уважение и т.д.
Вы упустили что если всегда работа делается хорошо это исключительно заслуга исполнителя и не кого то ещё.
Если уборщица работает хорошо соответственно это и есть фактор влияющий на доходность.
Ну так и ожидалось. Люди помнят только зло и хорошее принимают как норма, обязанность… а это не так.Zenitchik
11.01.2019 17:43Вы меня не прочитали, пишете о чём-то своём.
Ну так и ожидалось. Люди помнят только зло и хорошее принимают как норма, обязанность… а это не так.
Это Вы сами выдумали. Я писал совершенно не об этом.
Повторю свой вопрос: Вы бы согласились работать дворником в некоторой организации не за фиксированный оклад, а за долю от прибыли? Напомню, что Вы способны повлиять на прибыль только в меньшую сторону, а в большую сторону прибыль увеличивают другие.o4evidec
11.01.2019 19:11Вы ставите вопрос с заведомо зная логичный ответ. «Ахиллес и Черепаха»
И не хотите понять очевидное.
Именно стабильно качественное исполнение обязанностей дворника и есть причина той части прибыли за которые отвечает дворник.
Т.е. дворник влияет на прибыль. И идеально выполненная работа это и есть его максимум. Далее только уменьшение за не доработки…
Если вы не можете оценить в цифрах это не значит что этого нет. Довыды уже описывал.
Более того у дворника может выходить те же деньги при такой системе или больше если компания получила больше дохода что может только мотивировать исполнителя…
Я так не давно обсуждал с коллегами рациональность повышения зарплаты на сумму а не на % как принято в большинстве организации т.к. в случае с информацией дорожает жизнь а не растет доход компании и встретил аналогичную реакцию… мол все равно руководитель должен получить больше так как его оклад выше…
В общем если нынешняя ситуация и оплата по часам в 1С вас устраивает и это для вас нормально то наверно нет смысла дальше вести беседу в комментах про мотивацию…Zenitchik
11.01.2019 20:20И не хотите понять очевидное.
Скорее, наоборот.
Именно стабильно качественное исполнение обязанностей дворника и есть причина той части прибыли за которые отвечает дворник.
В том-то и дело, что нет. Стабильное качественное исполнение обязанностей дворника — это одна из причин ВСЕЙ прибыли, а не части её. Но у ВСЕЙ прибыли так же есть другие причины, не зависимые от дворника.
Вы согласны, что если прибыль компании уменьшилась по не зависящим от дворника причинам, дворник не должен потерять в деньгах?
Теперь другой вопрос: если компания получила больше дохода, и благодаря этому дворник получил больше денег, то к чему это должно мотивировать дворника, который и так стабильно и качественно исполняет свои обязаности? Исполнять их ещё лучше, хотя лучше уже некуда?o4evidec
11.01.2019 20:39По-моему вы противоречие сами себе…
Стабильное качественное исполнение обязанностей дворника — это одна из причини ВСЕЙ прибыли, а не части её. Но у ВСЕЙ прибыли так же есть другие причины, не зависимые от дворника
Так дворник на всю прибыл влияет или на ее часть?
Мотивация в том чтобы на следующей месяц получить также или больше.Zenitchik
11.01.2019 22:48Так дворник на всю прибыл влияет или на ее часть?
Потому что невозможно выделить ту часть прибыли, на которую влияет дворник. Он не может единолично отвечать ни за какую часть прибыли, потому что прибыль зависит от его действий через функцию с плато.
Мотивация в том чтобы на следующей месяц получить также или больше.
Допустим. И как он на это может повлиять? Думать «ах какой я мотивированный»?o4evidec
11.01.2019 23:28Попробую перевести аналогию.
Человек — Компания.
Человек производит услуги по копанию траншеи. Получает деньги — доход.
На полученные деньги покупает еду — накладные расходы без этого не как.
Покупает одежду — Охрана труда и т.п., принципиально можно без одежды но тело может пострадать.
Далее можно и не мыться — уборка, но опять может тело пострадать потерять связи с друзьями…
Можно ущемлять себя в удовольствии но опять может пострадать психика — корпаратив дух, и т.п.
Что мы делаем с ростом доходов. Покупаем лучшую одежду, лучший парфюм, более развлечений и удовольствий. И это норма.
В этом случае человек растет как индивидуум.
А что делает владелец большинства компании.?
Набивает пузо, толстеет, бухает, заставляет работать тело на износ, экономит на еде одежде и т.д. у него отказывает сердце, его меняет, и все в таком духе пока тело не откажет.
Можно ещё расписать но Надеюсь донес...DrPass
12.01.2019 00:17А что делает владелец большинства компании.?
Хм. У моей прабабушки была отличная поговорка: «Ценен не работник, ценен командир». Это очень правильная поговорка.
Потому что продукт создаёт не тот, кто лопатой машет, а тот, кто его придумал и может продать. Лопатой может махать легион. А вот организовать их вместе, обеспечить лопатами, найти тех, кто им будет траншеи заказывать, операционистов, которые будут заказы принимать, бухгалтера, охрану труда и т.д. — на это способны единицы. И вот за то, что они организовали бизнес, они и получают доходы намного выше чем те, кто умеет только махать лопатой. Или намного ниже. Если бизнес не получился, так тоже бывает.o4evidec
12.01.2019 08:33Согласен, каждому платить нужно за внесённый вклад.
Цену его услуг определит рынок.
Главное не платить окладом, иначе мотивации не будет.
DrPass
11.01.2019 18:10+1Личные деньги собственнике обеспечены кем? Уборщица вообще по вашему не участвует?
Участвует. Как уборщица. Выполняет одну фиксированную задачу за фиксированную оплату. Практически без вариативности, в отличии от, например, программиста или продажника. Она или убирает, или нет.
. Т.е. вы платите в любом случае больше не зависеть от вашего дохода.
Уборщица имеет полное право попросить больше денег за свои услуги, и если это предложение будет в рынке, на её условия согласятся.
вы попробуй те оценит любого сотрудника как именно того кто влияет на прибыль — партнера, а не как раба.
Любой сотрудник — ни в коем случае не раб, и ни в коем случае не партнёр по бизнесу. Партнёр инвестирует в наш бизнес свои личные средства, и делит со мной и прибыль, и риски. Сотрудник — это всего лишь поставщик услуг. Он ничего в бизнес не инвестирует, а за деньги продаёт своё рабочее время и свои навыки. И никаких рисков не разделяет — какие бы не происходили колебания с доходами компании, вплоть до полного гаплыка он свою зарплату будет получать.o4evidec
11.01.2019 19:57Участвует. Как уборщица. Выполняет одну фиксированную задачу за фиксированную оплату. Практически без вариативности, в отличии от, например, программиста или продажника. Она или убирает, или нет.
Очень логично… программист либо программирует либо нет… продажник либо продаёт либо нет… Ой а это не одно и тоже, не?
Дальше уже скучно. Вы разделили людей финансово, аргументируя что риски он не несёт и поэтому он будет получать оклад т.е. меньше… и пофиг на мотивацию, главное больше себе оставить а не мотивировать финансово увеличить прибыль. удобно?DrPass
11.01.2019 22:01Очень логично… программист либо программирует либо нет… продажник либо продаёт либо нет… Ой а это не одно и тоже, не?
Нет, не одно и то же. Мотивация — это не средство раздать всем побольше денег. Это средство убедить человека работать больше и лучше. Причем если от мотивации доход вырастает больше, чем было на неё потрачено, она имеет смысл. В противном случае не имеет.
Для ненормированной работы — самое то. Мотивированный продажник имеет массу способов сделать работу лучше, чем немотивированный. Программист — точно так же. Но что вы собрались мотивировать для должностей, труд которых строго нормирован, и результат что с премией, что без премии отличаться не будет? А если вдруг будет — то такой работник заработал пенделя под сраку, а не премию.
главное больше себе оставить а не мотивировать финансово увеличить прибыль. удобно?
Кого мотивировать увеличить прибыль? Уборщицу? Вы в своём уме?
Dementor
11.01.2019 16:49Простите, но вы пишите бред.
Роль «уборщицы» в армии — это поставщики продуктов в армейскую столовую. Если вас 10 лет обслуживает одно и тоже юрлицо, то будет ли это поводом платить им за макароны и кетчуп на 10% выше рыночных цен?
Поднимать зарплату уборщицам за выслугу имеет смысл только в клининговых компаниях. Если же уборщицы не являются исполнителями функций бизнеса, то чем они лучше арендаторов, электриков, сантехников, пожарников, санстанции, налоговиков и прочих сервисников, которые оказывают вам стандартное обслуживание на равных с другими магазинами, банками и детскими садиками, не вдаваясь в детали вашего бизнеса? Или вы искренне считаете, что чем дольше баба Глаша проводит уборку именно у вас, то тем она становится все моложе и моложе, физически ускоряясь и выполняя вместо одной генеральной уборки в месяц, уже по две-три?JamboJet
11.01.2019 19:39Хм, когда-то я работал простым рабочим на фабрике в США (штучная кондитерка), и там была четкая система с доплатами «за выслугу лет». В том конкретном месте — 0,25$ в квартал, как я помню. И простые упаковщицы сидя на одном месте 10 лет могли получать побольше своего супервайзора. Местами были даже семейные династии.
Как я сейчас догадываюсь, что логика в том, что это: устраняет текучку кадров (а значит и простои в работе, и необходимость содержания HR, рекламы и т.д.), ускоряет работу конкретного человека, ускоряет работу предприятия в целом (новички не становятся узкими местами на конвеере), обеспечивает накопление и передачу опыта.
Так что всегда надо оценивать риски, если новая уборщица недоуберет зал — ничего страшного, а вот если новый админ угробит систему за много_денег…
Сейчас я как раз на работе с высокой текучкой и в шоке от стратегии НЕдоплачивать за стаж 5тыс/р в месяц проверенному сварщику, он уходит, а его замена косорезит на миллион убытков. За эти деньги можно было двадцать лет доплачивать…Dementor
11.01.2019 19:51Не путайте вознаграждение за лояльность с обычной расточительностью. На вашей фабрике все рабочие работали по совместительству на 20 фабриках-конкурентах? А уборщицы обычно обслуживают по несколько офисов в день. Платить за то, что для твоего офиса нашли окошко в графике, когда вокруг есть десятки вакансий других опытных уборщиц — это за гранью здравого смысла.
Если бы я был директором некой фирмы и гипотетическая баба Глаша была душевной женщиной, которая поднимала своими историями настроение всему коллективу (типа уборщицы из сериала «Реальная мистика»), то я бы мог позволить себе щедрость выписать ей в течении года парочку премий к 8 марту и новому году. Но не больше.
sergeperovsky
12.01.2019 01:09В 50-х годах конструкторские бюро стимулировали очень простым способом: за сдачу проекта полагалась премия. Например в 6 окладов. Кому? Всем. У всего коллектива была одна цель и всевозможное наставничество возникало само собой. В начале 60-х было принято решение разрешить делить премию по КТУ. И наставничеству пришел конец. Сразу и бесповоротно. Делиться своими компетенциями стало невыгодно. Те, кто эту реформу застал удивлялись, как атмосфера в коллективе поменялась за месяц.
o4evidec
11.01.2019 17:11-1Клининговая компания тоже вариант. Если опять же зарплата будет зависеть от доходов.
Поставщика можно оценить по принципу не убил или не ослабил основную оборону страны, а ведь мог. Заслуга? Или такая же обязанность как у Раба?
А баба Глаша ценный сотрудник раз можно долгое время качественно мыть полы.
Это мало кто может понять пока она умышленно либо не умышленно протерет ядом поручни лестницы и тем самым не лишит Центробанка или Мерии большой части работников.
Большинство уже запрограммированы на типовое мышление, не явное рабство для своего вида для " нас" норма.
А те кто думают иначе — террорист. ))
Так и живём, порабащаем друг друга, как писал автор живём здесь и сейчас. При этом топчемся на месте и не развиваемся как могли бы…
o4evidec
11.01.2019 17:52Да не бойтесь пока вас больше таким как я не дадут захватить мир…. ))
Ну на самом деле кто более менее в шоколаде не захочет делится с уборщицами…
Все же надеюсь что подобные решения не только у меня и когда нибудь до растем до цивилизации а не выживании…Neikist
11.01.2019 19:36Слава богу. Я бы не хотел жить в вашем мире где работники несут риски бизнеса вместо его владельца.
Dee3
Такое ощущение, что я это уже читал
Dementor
Это переработанная прошлогодняя серия статей «Золотой франч».
infostart.ru/public/834185