Миллионы на сопровождении

 

Меня зовут Николай Елатонцев, я – исполнительный директор компании ООО «Гильдия консультантов». Тему сопровождения я изучил достаточно глубоко:

• Я уже много лет управляю отделом сопровождения.

• Моя компания, в том числе, является разработчиком собственного программного обеспечения ServiceDesk – именно для IT-компаний.

• И для сопровождения проектов я разработал свою методологию, о которой сегодня расскажу.

 

Четыре важных момента про доклад.

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

• Главная работа отдела сопровождения – это отгрузить часы. Мы – маленький завод по производству часов. Производим и отгружаем. У нас одна фундаментальная метрика – это непосредственно стоимость часа.

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

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

 

Почему модель Time&Materials показала себя самой оптимальной в период турбулентности 2022 года

 

 

Два слова про модель Time and Materials.

Time and Materials – это модель работы, при которой оплачивается не результат, а время исполнителя. Фундаментально о ней можно долго спорить, но она очень вкусная для подрядчика. Это нужно понимать.

 

Когда наступил февраль 2022 года, многие проекты застопорились, потому что некоторые компании перестали вообще что-либо внедрять.

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

 

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

Например, у нас сопровождение проходит через трехмесячный цикл:

• в первый месяц мы часы отгружаем;

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

• и в третий месяц мы на них живем.

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

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

 

Модель Time & Materials позволяет нам быть гораздо устойчивее и хорошо себя чувствовать. В турбулентный 2022 год эта модель показала себя самой оптимальной.

 

Теперь важный инсайт, которым мне хочется поделиться.

• В сервисной компании хороший сервис не зависит непосредственно от качества программирования.

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

• И компания со стоимостью часа в 3000 рублей, и фрилансер за 500 могут сделать задачу как одинаково хорошо, так и одинаково плохо. Это очень важно понимать.

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

 

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

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

Именно этот момент предсказуемости и ложится в основу нашей методики.

 

Как правильная методология оказания услуг и организация ServiceDesk позволяет повысить LTV клиента вдвое

 

Второе, на чем нужно сосредоточиться, это LTV, Lifetime Value.

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

• Предсказуемость для клиента – это не выходить за оценку задачи, исполнять сроки и SLA. Именно в таком виде мы для себя понимаем предсказуемость.

Как же увеличить этот LTV, чтобы и клиент был счастлив, и компания не испытывала недостатка финансов?

 

База

 

Тикетогенерация. Чтобы привязать баланс клиента к трудозатратам по тикетам нужна единая база:

• Должен быть хотя бы минимально внедрен какой-то ServiceDesk.

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

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

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

Необходимо привязать деньги к работе и сосредоточиться на этом. Для этого вводится сущность «Баланс».

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

Это то же самое, что и телефон. Деньги положили, а потом посмотрели, за что они списались. Очень удобно.

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

 

Структура отдела сопровождения. Какой она должна быть?

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

Если у вас в отделе сопровождения много сотрудников, мы рекомендуем использовать юниты:

• для всех юнитов есть общий руководитель;

• в каждом юните есть старший;

• и есть исполнители каждого юнита;

• при этом юниты относительно друг друга не пересекаются – это достаточно самостоятельные единицы.

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

Процесс:

• задача появляется в сервис-деске;

• старший юнита эту задачу анализирует – у нее появляется срок и оценка;

• после этого оценка утверждается;

• выполняется;

• тестируется;

• и заливается на прод тем же старшим.

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

 

Как за счет трекинга и отчетов по выполненным задачам можно поднять стоимость часа на 25%

 

При работе с задачами:

• Сотрудник трекает транзакцию в часах, клиент видит ее в деньгах.

• К сожалению, даже в модели Time and Materials есть моменты, которые не идут в оплату.

• С точки зрения руководителя, при модели Time and Materials вроде все должно идти в оплату, помимо каких-то конкретных вещей вроде стандартного простоя.

• Но бывает, что задач вроде много, а в оплату затрекано три часа из 6 или 8. Кто-то использует 8-часовой рабочий день, а кто-то 6-часовой, потому что программисты не умеют все 8 часов программировать. Они программируют где-то 6 часов, а в остальное время им нужно поговорить, отдохнуть, перекурить, потянуться, поржать, мемасы посмотреть. Стандартно 8 часов никто не работает, хотя некоторые компании на это говорят: «Вы что, издеваетесь? Да они уволены будут!»

• Все это очень сильно влияет экономику.

 

Рассмотрим пример:

• У нас есть крутая жирная задача на 30 часов.

• Учитывая стоимость часа – 2000 рублей – мы должны получить за нее 60 тысяч рублей.

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

• Соответственно, стоимость часа у нас уже падает до 1935 рублей.

 

Идем дальше.

На изучение штатной функциональности специалист наверняка потратил 3 часа. Потому что любому человеку, чтобы вникнуть в задачу, нужно время, если он ни с чем подобным раньше не работал. Если мы изучаем лютый кастом, мы, разумеется, это все в оплату ставим. Но ставить в оплату изучение штатной функциональности, наверное, не очень красиво. Соответственно, количество часов, выставленных в оплату, уменьшается до 27 часов. И оплата специалисту – 54 тысячи рублей.

Но фактических часов у нас все так же 31. Стоимость часа уже 1740 рублей.

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

Итого у нас получается 54 тысячи рублей, 27 в оплату. Фактически – 32 затраченных часа. Стоимость часа уже понизилась до 1690 рублей.

 

Пользовательское тестирование – 1 час – мы можем поставить в оплату.

Получается, что задача у нас стоит клиенту уже 56 тысяч рублей – это 28 часов в оплату при 33 фактических. Стоимость часа не изменилась – 1690 рублей.

А вот исправления иногда можно добавлять в оплату. Но когда ошибку нашел сам клиент, наверное, брать с него деньги за исправление некруто. Поэтому 30 минут исправления у нас пошло в оплату, а еще 30 минут – за наш счет. Таким образом у нас получается 57 тысяч рублей – это 28 с половиной часов в оплату за 34 фактических часа. Стоимость часа – 1680 рублей.

 

Обратите внимание, мы по дороге потеряли 16 процентов стоимости часа.

Получается, что в этой задаче у нас стоимость часа не 2000 рублей, а 1680.

Это все начинает очень сильно влиять на экономику.

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

 

Чтобы решить эту проблему, нужно трекать все:

• Часы в оплату;

• Помощь;

• Изучение типовой функциональности;

• Инфраструктурные задачи;

• Работу по реквестам;

• Бесплатные работы с указанием причины, что там: ошибка, кончились часы и т.д.

• Простои и отсутствия на рабочем месте тоже трекаются;

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

Все это трекается, трекается и трекается. А зачем?

 

Ради денег, разумеется.

• Когда вы начинаете видеть фактические затраты, вы можете непосредственно влиять на ежедневную выручку.

• Вылезают задачи, которые тянут вас вниз и едят ресурсы.

• Вы или размазываете эти бесплатные задачи по платным, чтобы заработать за неделю нормальные деньги.

• Или устраивайте бесплатные недели во «Вкусно и точка»

 

Но что еще важного дает такое постоянное трекание:

• Клиент видит все транзакции в онлайне – что вы сделали и когда.

• Не надо делать отчеты – это очень круто. Статистику можно сформировать автоматически за любой период.

• Вся эта система начинает круто работать, когда клиент не хочет платить. Когда он говорит: «Вы плохо делаете, вы нарушили сроки. Обещали за два дня, а я этого не получил»

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

Важно: трекайте в кратных величинах – либо 5, либо 10 минут. Иначе вы где-то по две-три минуты не доберете, а где-то – переберете. Поэтому округляйте.

 

Нужны отчеты, показывающие:

• Сколько зарабатывает сотрудник/юнит/отдел в деньгах за отчетный период.

• Сколько часов тратит сотрудник/юнит/отдел не в оплату, и по какой причине. Во всех разрезах. Есть причины типа «Изучал функциональность», а есть ошибка или неправильная оценка.

• Ошибки или задачи с неправильной оценкой должны уходить в ретроспективу.

• И задачи, где исполнители не справились по часам, – тоже в ретроспективу.

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

Когда у нас появляются такие отчеты, мы получаем:

• Понимание, почему не выполняется план.

• Реальную стоимость часа на задачах и проектах. У нас были проекты, на которых стоимость часа оказалась 160 рублей. Когда проект заруинен, но его нужно сдать, и мы видим, что стоимость часа у нас по этому проекту не 2000 рублей, а 160. Такое тоже бывает. Это когда большая задача и договор не в формате Time and Materials, а на какой-то конкретный объем выполненных задач. Что-то там не доглядели и погнали.

• Фиксацию убыточных проектов и задач – все фиксируем и думаем, что теперь с этим делать.

• Информацию, как отработали юниты и отделы за отчетный период.

 

Включая в этих отчетах детализацию по транзакциям, мы можем видеть и другие очень важные вещи:

• Понимание того, насколько быстро сотрудник изучает новую функциональность.

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

• Понимание того, сколько времени нужно тратить тимлиду на молодых.

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

• Понимание того, на что уходит время у сотрудника с точки зрения задач – можно видеть, насколько быстро он въезжает в задачу.

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

 

Как правильная система отчетов позволяет увеличить производительность отдела в 1,5 раза без увеличения количества человек

 

Это трекание также помогает разруливать задачи между менеджерами и программистами.

У нас программисты – это исполнители. Они, как правило, с клиентом по телефону не общаются, сроки сами не контролируют, только программируют. И есть менеджеры, которые уже несут дополнительную ответственность. Нужно выстроить между ними какое-то хорошее взаимодействие. Что мы для этого рекомендуем?

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

• И здесь важно помнить про LTV и предсказуемость сроков и оценки. И тут как раз возникает момент контроля – что делать, если мы выходим за рамки сроков и оценки.

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

• В результате между менеджерами и исполнителями могут возникать стандартные конфликты из-за противоречий интересов.

Как сделать общение исполнителей и менеджеров безболезненным? Очень просто:

• У исполнителя в задаче есть оценка и срок.

• Пока он не выходит за эти рамки, к нему никто не лезет, и исполнитель об этом знает.

• Как только по оценке или по сроку обнаруживается нарушение – например, менеджер видит, что задача оценена в 2 часа, а фактически потрачено уже 2:30 – есть причина получить комментарий от исполнителя. Исполнитель пишет нормальный комментарий.

• Менеджер со своей стороны тоже трекает, что он предпринял по задаче – в данном случае о том, что спросил, и какой получил ответ.

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

Соответственно,

• Исполнитель понимает, что задача менеджера – не допустить роста стоимости и срока выполнения.

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

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

 

Ретроспектива

 

Мы уже упоминали, что по итогам недели важно анализировать трекинг по задачам. Для этого проводится ретроспектива:

• Ретроспектива – это аналитика прошедшего спринта, как правило, за неделю.

• Анализируем работу менеджеров и исполнителей в разрезе нарушения сроков и оценки – это важно, это наша предсказуемость, это влияние на LTV.

• Анализируем работу исполнителей в разрезе всего потраченного времени спринта – что вообще сделал исполнитель за 30 рабочих часов.

• Анализируем работу старших в разрезе аналитики – сколько раз они ошиблись в оценке, это очень важно.

• И соответственно, анализируем разрез задач – почему те или иные задачи не были выполнены в оцененный срок. Это уже может быть непосредственно из-за исполнителя.

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

 

Почему 30% компаний не могут исполнить заявленные SLA, и как этого избежать

Необходимо внедрять SLA (Service Level Agreement):

• SLA – соглашение об уровне предоставления услуги, ее соблюдения или несоблюдения.

• Если у вас больше 10 заявок в день, вы теряете предсказуемость. А предсказуемость для нас – это все.

• Важно выполнять то, что задекларировано в SLA.

Что нужно описать в SLA:

• Время работы отдела – потому что многие клиенты уверены, что мы должны работать 24 на 7, мы же хостинг. Они не понимают, что мы программисты: «Как так? А если что-то случилось?» Нужно четко сказать – мы работаем с 9:00 до 18:00, мы прогеры, на случай аварии все откатим. Это все в договоре должно быть.

• Время реакции на новый тикет должно быть прописано обязательно.

• И время ответа – если уже задача взята в работу, должно быть известно максимальное время ответа.

У тикетов есть статусы. Статусы – наше все.

Какие напоминания мы рекомендуем добавить в свою внутреннюю систему учета тикетов, чтобы выполнять SLA:

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

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

• Напоминать о том, что последним в тикет написал клиент, а значит, надо дать обратную связь.

• Что неверный статус.

• Что необходимо сообщить о прогрессе.

• Что нужно клиенту напомнить о задаче.

Вот такие напоминалки очень отлично пропихивают задачи, а когда 160-170 открытых задач, в них действительно можно немного потеряться.

 

Опять же, зачем это делать? Разумеется, ради денег:

• Если мы предсказуемы, лояльность повышается.

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

• Задачи решаются быстрее – это получается уже автоматически.

 

Планирование

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

• Без плана при большом количестве задач мы становимся непредсказуемы для клиента.

• Значит, нам план нужен.

• Есть два вида планирования: нагрузка на команду и финансы.

• Нагрузка планируется ежедневно, финансы планируются на неделю.

 

Как производится планирование нагрузки и планирование финансов:

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

• А при планировании финансов все просто. У вас есть люди – вы умножаете их рабочее время на стоимость часа. Этот максимум ставите им как план за неделю. И смотрите, сколько этот план будет исполняться, какая у них загрузка.

 

Пример такого «производства»:

• 10 сотрудников;

• план – закрывать 60 часов в день;

• вычитаем 15% часов в неоплату – будут же ошибки, мы же не идеальны;

• умножаем на стоимость часа, получаем 510 тысяч рублей.

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

 

Договоры, база знаний, тестирование без отдела тестирования. Как вспомогательные истории влияют на экономию денег и времени

 

Когда проект большой, по нему нужна база знаний:

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

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

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

 

Так как накапливать знания, чтобы ими было и пользоваться удобно, и данные там сами заполнялись?

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

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

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

Вот так мы победили заполнение базы знаний, и сейчас отлично этим пользуемся.

 

Тестирование без отдела QA. Еще хотел рассказать про тестирование.

• К сожалению, отдел QA мало у кого есть, особенно у сервисных команд.

• Клиент не понимает, за что платить: «Я вам вообще-то плачу за нормально выполненную работу, какое тестирование 60 часов, вы что?»

• Отдельного человека на это мы взять не можем – у него не будет столько работы.

 

Что мы рекомендуем для решения проблемы тестирования:

• чтобы тест, проверяющий функциональность, писал сам исполнитель (программист);

• а тестировал по этому тесту другой человек (другой программист или свободный менеджер);

• при этом в задачу просто добавляется два статуса – «На тестировании» и «Тестирование пройдено»;

• и все, и 90% ошибок ушло.

Через такую круговую поруку у нас получилось организовать тестирование без отдела QA – это стало отличной историей.

 

Договор. Пару слов про договор – на что обратить внимание:

• Предмет договора. В предмете нужно указать – услуги сопровождения или технической поддержки.

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

• Дальше нужно указать стоимость часа и период оплаты.

• Порядок приемки.

• И приложить регламент.

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

 

У нас на каждый чих есть затреканная бумажка. Такую практику наши ребята называют «Бюрократией 2.0».

• У нас есть отдельный талмуд о том, как работать с системой, какие статусы должны быть у задачи, почему все нужно трекать.

• В нем описано: что трекать, когда трекать, как реагировать на то или иное действие ответственным лицам.

• В итоге решение задачи – один час, а ее выполнение по протоколу – два часа.

• К сожалению, по-другому не бывает. Все это нужно, чтобы мы были предсказуемы.

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

 

Вопросы

 

Какую средненедельную загрузку на одного разработчика вы берете при планировании? Сколько часов?

При планировании должна быть полная загрузка, 30 часов в неделю.

Должна быть, а по факту?

А по факту бывают 50% загрузки, бывают 75% загрузки – это неисполнение плана.

Вопрос возник из-за того, что при финансовом планировании у вас стоит показатель 6 часов, который вы умножаете на 5 дней. И минусуете от этого 15%. Получается вы уже 2 часа на что-то отбрасываете.

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

По факту получается где-то 5-6 часов из восьми?

Да, это хорошо.

Есть некоторые сотрудники, которые все делают очень быстро. А есть те, которые очень тормозят. Может ли быть такое, что тот, кто все делает быстро, за день выполняет 150% плана? Например, он взял задачу, которую оценили на 16 часов и выполнил ее за 6 часов?

Нет, потому что у него в плане стоят запланированные отработанные часы – он больше 6-7-8 часов в день не закроет. Мы не планируем выполнение задач.

Если оценка была, например, 20 часов, а он выполнил за 10, мы смотрим уже по факту. И говорим клиенту, что ему круто повезло, что его задачу выполнили настолько быстро. Получилось, что мы о чем-то не знали.

150% выполнения плана не должно быть – это значит, оценки были завышенные.

Если прогнать задачи по ретроспективе в течение 2-3 месяцев, они ставят очень реальные сроки. При оценке важно продумать не что ты сделаешь, а как ты будешь делать. Создание справочника, создание инфоблока, написание обработки. Что тебе для этого нужно? Декомпозиция – наше все.

150% плана у нас никто не выполняет. Потому что планируются часы, больше 8 в сутках никто не отработает.

А часы как-то делятся на фактические и выставляемые клиенту?

Нам важно сохранять предсказуемость.

Клиент ставит задачу. Даже если это кастом, где он платит за аналитику, например, 2-3 часа, после этого он получает оценку задачи – например, 15 часов.

После этого мы ставим срок, плюс накидываем еще один день, когда она на проде появится – там должны пройти еще какие-то свои вещи.

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

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

Сразу. Как только ты что-то сделал: прикоснулся к проекту, раскатал инфраструктуру – ты тут же затрекал. Если ты зачем-то вошел на проект, то сразу, как вышел, затрекай, что ты сделал.

Если ты вошел на 20 минут, чтобы помочь, а потом ушел что-то свое делать, затрекай 20 минут.

Может получиться так, что исполнитель еще часа своего не проставил, а там уже набежало – аналитика, раскатка инфраструктуры, что-то еще.

Это уже когда вы взяли задачку, а когда вы ее еще не взяли? Как вы учитываете трудозатраты на первичный обсчет?

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

Но при этом не факт, что по ней будет заключен договор?

Нет, у нас договор заключен уже с клиентом. Он не получает доступ к этой системе, пока нет договора. У нас с ним уже заключен договор на поддержку или сервисное обслуживание.

Допустим, я – клиент, я прихожу и говорю: «Я хочу вот такую фишку. Сколько это будет стоить и сколько это будет в днях?» Вы же должны это как-то посчитать. Это трудозатраты нулевой фазы.

Это додоговорные отношения. Очень часто оценкой занимается тимлид или я. Эти трудозатраты, конечно, никуда не идут.

Но если потенциальный клиент дает нам декомпозицию на 150 задач и просит обсчитать, мы это не делаем.

Бывают ли ситуации, когда вы оценили в часах и в сроках, а клиент от этой задачи отказался?

Бывает. В этом случае оценка не идет в оплату. Старший затрекал 20 минут на изучение, но задача в работу не ушла.

Это скорее как косвенные расходы, которые высчитываются потом просто с общемесячной маржи. Это нормальная история.

Мы сейчас пока держим стоимость часа 2 600. Соответственно, любая задача в 30 часов – это уже больше ста тысяч. А когда клиент начинает это понимать, он не готов платить.

У вас отдельно ведется учет часов, которые вы анонсируете для клиента, и внутренних часов, затраченных фактически?

Да, конечно. И может быть такое, что стоимость часа для всех 2 600, но клиенты разные – один геморный, а второй лайтовый.

У геморного клиента за счет ошибок ребят или еще чего-то стоимость часа может сваливаться до 1800. А лайтовый все принимает, ему все нравится, и вообще сайт примитивный, и задачи большие.

Получается, что это, по сути, серая касса.

А задачи на 15 минут вы тоже прогоняете через все это согласование, оценку и т.д.?

Да, у нас бюрократия.

Какая у вас средняя трудоемкость задачи?

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

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

А средняя трудоемкость – это ванильная метрика, она ничего не даст.

Программистам оплачивается час за длинные задачи и за маленькие задачи одинаково? Потому что проектными задачами проще заниматься – там все в одном направлении.

Я согласен, что всегда проще не прыгать с проекта на проект. Но в сопровождении так редко бывает.

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

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

А зачем работать в таком режиме хорошим программистам, которые могут делать задачи быстро?

Такие программисты у нас, как правило, старшие. Они делают оценку, иногда сами делают задачи, если им хочется. Оценку всегда делают они.

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event.