Продолжаем кейс для франчайзи, цель которого – повышение выработки вдвое. Первая часть – здесь, вторая – здесь. В первых двух частях мы обсудили предпосылки и подготовительную работу.
Сегодня – сам процесс работы. Но сначала – о главном принципе.
Главный принцип
Многие задаются вопросом – как такое вообще возможно, что выработка вырастет вдвое? За счет чего? Мы что, код сможем быстрее писать? Или снизим его качество? Тяп-ляп и в продакшн? Многие, конечно, не задаются, а просто отрицают и отвергают. Ведь невозможно, чтобы была где-то проверенная методика двукратного ускорения, а никто о ней не знал?
Проблема, на самом деле, банальная – неправильный вектор внимания. Или, проще говоря, вы не туда смотрите. Сузим тему до программистов, хотя принцип универсален.
Какова, по-вашему, идеальная скорость решения задачи клиента программистом 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С пока не все хорошо с методами повышения эффективности. Собственно, эту проблемы мы и устраняем данным кейсом.
Когда выберете дежурного, дайте ему ссылку на статью, приведенную выше. Главное, что он должен понять, принять и исполнять – за статусами задач нужно следить.
Каждое его утро должно начинаться с ритуала – управления статусами задач. Это очень просто и легко автоматизируется. В первом окне – новые задачи, еще не принятые в работу. Это – список для обсуждения с командой, которое мы рассмотрели выше. Итогом обсуждения должно стать опустошение этого окна.
Во втором окне – задачи, принятые в работу, но не имеющие исполнителя. Опустошается так же, после общего обсуждения. По итогам обсуждения оба списка должны стать пустыми. Допустимое время нахождения задачи в статусах «Не принято в работу» и «Не назначен исполнитель» - не более одного рабочего дня.
Если задача не понятна, и требуется уточнение заказчика – задача, вместе со списком вопросов, переезжает в окно/статус «Требуется уточнение» или «Отправлено на доработку» - не важно, как назвать. Важна детерминированность.
После обсуждения (или перед ним) дежурный проверяет список отправленных на доработку, чтобы не было просрочки статусов. Например, на уточнение постановки отводится три дня. Прошло три дня – надо написать заказчику, чтобы не тормозил. Он, с высокой вероятностью, просто забыл ответить.
Во время обсуждения с программистами смотрим на окно «В работе». Оно у нас ранжированное: все понимают, кто какой задачей занимается. Соответственно, есть время нахождения задачи в статусе «В работе», с привязкой к исполнителю, и это время надо контролировать.
Банально – для того, чтобы не пропустить границу времени познания для новичка. Если ему дали сутки на самостоятельное решение, и эти сутки прошли, то он, с высокой вероятностью, не поднимет руку и не скажет, что не справился. Будет тупить до последнего. Нам это не надо, поэтому банальный контроль за временем жизни статуса спасет от лишних потерь, а новичка – от чувства вины за свою тупость.
Последнее окно – выполненные задачи, требующие акцепта от заказчика. Тут принцип такой же, как в отправленных на доработку – ставим срок, например, три дня, после которого начинаем напоминать о себе. Спокойно, уверенно, но настойчиво. Повторю, заказчик мог просто забыть, у него своих дел хватает.
Продолжение следует. По материалам https://business-programming.ru
