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

Также здесь мы собираемся осветить некоторые вопросы внутренней организации, решающиеся в разных компаниях по разному (и нигде — 100% удовлетворительно) и представляющие общий интерес для любого бизнеса, связанного с разработкой софта.

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

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

В первой серии рассмотрим организацию бизнес-процесса поддержки.

Традиционно, сначала определимся со значениями слов.

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

Обслуживающий партнер Ultima, он же просто партнер — собственно, организация, авторизованная компанией Ultima для продаж, внедрений и поддержки собственных продуктов. Если по-простому — аналог 1С-франчайзи, а если многа букоф и во всех деталях — то вот . Далее в тексте будем просто использовать “мы” и производные.

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

Задача — она же Change Request или заявка на изменения, или просто заявка. Описание того, что необходимо изменить в программе. Заявки создаются сотрудниками клиента, по необходимости с помощью включения в процесс бизнес-аналитиков. Все заявки хранятся и обрабатываются в трекере.

Трекер — система обработки заявок на изменения (Change Request Management System). В нашем случае — веб-интерфейс для внесения, просмотра состояния и всего множества остальных операций с заявками. Трекер, в свою очередь, является частью ERP-решения, эксплуатируемого нами для собственных нужд. Естественно, на платформе Ultima Businessware.

Сапожник с сапогами, да.

Заказчик — сотрудник клиента, создавший заявку в трекере.

Ответственный сотрудник — сотрудник клиента, у которого есть права на передачу заявок в трекере в работу. Иными словами, утвердить заявку к реализации. На практике у клиента есть много сотрудников (заказчиков), которые могут создавать заявки, однако передавать их в работу могут только ответственные сотрудники.

Труд по имплементации заявок оплачивается клиентом по старой доброй схеме Time&Material.
Итоговая стоимость реализации стоимость заявки равна произведению количества потраченных часов на почасовую ставку.

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

А вот теперь уже непосредственно к устройству бизнес-процесса поддержки.

Пойдем по этапам.

0. Идея

У сотрудника клиента возникает идея.

Или проблема.

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

1.Формулировка заявки

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

Каждая заявка имеет три свойства, существенно влияющие на ее процессинг и итоговую стоимость, а именно:

• приоритет
• запрашиваемая квалификация исполнителя
• объем\сложность задачи

Кроме того, заявка имеет признак ошибка (ошибка или нет), и может хранить ссылку на “родительскую” заявку.
Рассмотрим подробнее каждую из них.

1.1. Приоритет

Приоритет заявки, как несложно догадаться из названия, влияет на ее скорость выполнения.
Приоритет — набор из трех вариантов:

• Обычная (по умолчанию)
• Срочная
• Критическая

Заявки с критическим приоритетом выполняются в любое время дня и ночи, срок реакции определяется в SLA (обычно, в рабочее время — до 15 минут, в нерабочее — до часа).

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

Наличие у заявки повышающего приоритета означает наличие повышающего тарифного коэффициента к базовой стоимости часа.

1.2. Запрашиваемая квалификация исполнителя

Сертифицированный разработчик Ultima для коммерческого использования квалифицируется по трем уровням:

• Junior Developer
• Developer
• Senior Developer

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

Джуниор — понижающий коэффициент, Сеньор — повышающий.

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

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

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

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

Почему так:
Оценка задачи - магия, конъюктурщина, субъективизм и прочее. В реальности оценка задачи делается так - по ощущениям надо 2 дня, но тут ничего не понятно, поэтому скажем неделя. Дальше ситуация развивается по 2-м путям (есть еще третий, мифический - когда план с фактом совпадает). 
1. Сделали быстрее, заказчик заплатил за неделю. Ну просто заказчик переплатил. Мелочь, как говорится, а приятно.
2. Делаем делаем, и тут начинаются какие-то доделки, уточнения и прочее. И заказчик рассказывает, что под словами “создается счет” он имел ввиду, что он еще и автоматом экспортируется, куда-нибудь импортируется, и так далее. В итоге, неделя проходит, а задача только продолжает увеличиваться. Тратим кучу времени на переоценку, пересогласования, выяснения это вообще все еще та же задача про бабочек на экране, или уже отдельная.

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

На практике оценщик, будучи лишним звеном в цепочке, пойдет по пути наименьшего сопротивления и минимизации геморроя - то есть потребное время будет максимально завышаться. Тут же сразу возникает питательная почва для коррупционных связок с программистами - часовую задачу оценили в недельную, бабло пополам. И ничего потом не раскопаешь - попадание в “план” 100%. Понятно, к чему приведет такое развитие событий как в разрезе отношений с клиентами, так и длительных рыночных перспектив компании.

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

Читатель “в теме” наверняка спросит: а где противовес завышению часов со стороны разработчиков? Контроля то никакого нет. Противовес такой: система оценок заказчиков (ниже), постоянный плотный контакт с клиентами на предмет оценки удовлетворенности (ниже), и пистолет вдобавок к добром слову: в единственно всплывшей ситуации приписок старый заслуженный сотрудник был немедленно уволен с позором и распубликованием.

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

1.3. Объем\сложность задачи

Опять таки, заказчик выбирает из трех вариантов:

• Мелочь
  Подвинуть кнопку, сделать хинт, добавить простую проверку и предупреждение и т.д. Грубо говоря, в пределах часа.
• Задача (по умолчанию)
  Например, новая печатная форма, отчет и так далее. Несколько часов и до дней.
• Мегазадача
  Комплексное сложное изменение бизнес-процессов. Например, изменение работы доставки. Появление собственного мини-производства салатов в супермаркете. Открытие направления посылочной торговли. Появление собственных зарубежных закупок и прямого импорта.

Границы между значениями объема\сложности — весьма нечеткие, и, честно говоря, — почти полностью субъективные.

Характеристика объем\сложность задачи используется в механизме автоматической диспетчеризации задач между пулом программистов.

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

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

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

2.Диспетчеризация заявки
Итак, теплый клетчатый робот определяет исполнителя самостоятельно.

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

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

Исполнитель при получении критической задачи прекращает работу над текущей задачей (если вообще время рабочее).

Срочные и обычные заявки обрабатываются только в рабочее время.

Можно считать, что у каждого разработчика есть 3 очереди задач (по приоритетам).
В работу задачи поступают только после исчерпания очереди с высшим приоритетом, разработчик должен разобрать все срочные задачи прежде чем получит задачу с приоритетом обычная.

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

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

Стоит заметить, что разработчики сами формируют свой рабочий календарь указывая когда и как они работают — т.е. на каждый день указывают в какие часы они будут работать.

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

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

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

Выдерживание разработчиком прогнозных дат сдачи заявок позитивно влияет на доход (подробнее о формуле мотивации разработчиков — в следующих сериях).

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

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

3.Разработка

Разработчик в интерфейсе трекера в любой момент может посмотреть очередь своих задач (точнее 3 очереди — по приоритетам), какая заявка назначена на него в текущий момент, есть уведомления о поступлении новых задач. Проделав необходимую работу, разработчик вносит потраченное на заявку время. Если задача занимает больше одного дня, то вносит данные о потраченном времени каждый день.

Задача разработчика — сделать то, что его просят в заявке.

Часто (особенно если заявка ставится без помощи аналитика), разработчик может предложить те или иные улучшения по заявке (выступая в некотором смысле в роли аналитика).

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

Если у разработчика это получается — у него большие шансы стать бизнес-аналитиком.

В помощь разработчику — интеграционные тесты, контрольные карты проверок (список того, что должен разработчик проверить чтобы уж совсем не накосячить), механизмы верификации в платформе etc.

Закончил — молодец.

Выполненная задача передается в тестирование.

4.Тестирование

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

Тестировщиков у нас нет.

Почему так.
Правильный тестировщик - человек, который понимает задачу на уровне разработчика, а систему знает на уровне заказчика. Это раз.
Во-вторых, в распоряжении идеального тестировщика должен быть аналог всего аппаратного комплекса (включая специфическое производственное оборудование, интегрированное с системой), используемого заказчиком, включая людей.
В-третьих, идеальный тестировщик должен быть настолько ответственным в своей работе, как будто ему предстоит эксплуатировать результаты своего труда.
В итоге рисования портрета идеального тестировщика явственно проступают черты заказчика. 
Если отвлечься от  идеала и посмотреть на правду жизни - то штатный тестировщик для программиста - исключительно удобный аргумент полностью положить болт на качество собственного труда. “Чо, заказчик недоволен? Херню сделали? Ну так тестировщик виноват, плохо оттестировал”.
Это не говоря о дополнительных затратах на содержание гарантированно бесполезных дармоедов - которые в итоге, естественно, оплачивает клиент.

Итак, за качество выполнения заявки (материально) ответственен программист.

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

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

5.Приемка

Если заказчик соглашается принять заявку, он отмечает ее как принятую. При этом система предлагает его оценить работу по заявке по следующей шкале:
— ни в какие ворота не лезет (2)
— через пень-колоду, но победили (3)
— хорошо, хотя и не без шероховатостей (4)
— блестяще, невозможно пожелать лучшего (5)

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

За оценку 5 разработчик получит премию, за оценку меньше 4-х будет депремирован. 2 — разборки.

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

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

Более того, на общее настроение клиента влияет (иногда в большей степени чем все остальное) работа аналитиков.
Поэтому ежеквартально партнерский центр Ultima проводит опрос клиентов по теме интегральной оценки уровня удовлетворенности сотрудничеством. Анкету я процитирую из статьи о поддержке на нашем сайте:
A
Использование решения Ultima оказывает явное положительное влияние на операционные показатели компании. Консультанты обслуживающего партнера Ultima проявляют высокую бизнес-компетентность и регулярно предлагают эффективные решения для оптимизации бизнес-процессов, ведущие к росту прибыли и/или сокращению затрат.

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

C
ERP-система Ultima внедрена и работает.
Каких-то прочих существенных достижений не отмечено.

D
Нас обманули. На практике ничего общего с тем, что вы обещаете на вашем сайте.

В заключение

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

В следующих сериях:
Мотивация программистов. Роль бизнес-аналитиков и их мотивация. Идеология подхода к внедрениям Ultima. Письма читателей.

Автор благодарит Ultima Consulting за неоценимую помощь, как собственно в построении бизнес-процессов компании, так и в создании настоящей серии.