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

О том кто же является контроллером, а кто моделью под катом.

В этой статье предполагается, что читатель знает, что такое MVC.

При построении модели я иду на умышленные упрощения.

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

Действующие лица

Заказчик — лицо, которое заказывает продукт или проект. Может быть как внешним, так и внутренним.

Компания (исполнитель) — сторона договорных отношений с Заказчиком.

Менеджер — лицо, которое взаимодействует с Заказчиком и конечным исполнителем (программистом). Принимает на вход задачи от Заказчика, транслирует эти задачи Исполнителю и возвращает Заказчику результат.

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

Процесс

Процесс заказной разработки выглядит примерно так:

1. Заказчик ставит задачу перед Компанией.
2. Компания, выступая маршрутизатором, доводит задачу до Менеджера.
3. Менеджер уточняет детали с Заказчиком.
4. Менеджер ставит задачу Программисту.
5. Программист выполняет задачу и передает выполненную задачу.
6. Менеджер выявляет недостатки и возвращается к пункту 4.
7. Если недостатков не выявлено, то Менеджер передает задачу Заказчику.
8. Заказчик выявляет недостатки и возвращается к пункту 3.
9. Если недостатков не выявлено, то Заказчик оплачивает работу.

Самым сладким пунктом для Компании является пункт 9. Но путь до него обычно долго и тернист.

Проблема такого процесса

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

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

Менеджер ставит программисту задачу проговаривая ее голосом или в чатике. Уточнения по задаче нигде не фиксируются. Программист постановку задаче вроде бы понял. Но разумеется понял по своему, а не так как объяснял менеджер (с точки зрения менеджера). Так как постановка задачи не зафиксирована, то каждый из участников трактует ее по своему.

При таком подходе появляется много итераций 4-6 и 3-8. Хорошего менеджера от плохого отличает соотношение между числом этих итераций. У хорошего менеджера число попыток сдать задачу заказчику равно единице. И попытка, как вы догадались, сразу удачная. При этом итераций по сдаче работ с программистом может быть много. Маршрутизатор не перепроверяет ничего за программистом и просто передает задачу Заказчику. И число итераций 3-8 достигает максимальных значений и равно числу итераций 4-6. И разумеется во всем виноват программист, ведь с точки зрения менеджера он плохо выполнил задачу.

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

Что же делать, чтобы избежать такие нежелательные явления?

Ассоциации

Давайте посмотрим на упрощенную схему работы с Заказчиком:

Опытный разработчик увидит полное совпадение с MVC:

Очень просто провести сопоставление сущностей.

• Заказчик = User
• Менеджер = Controller
• Исполнитель = Model
• Результат работы = View
• Компания = Приложение целиком

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

Первые шаги в починке

Какие инструменты у нас есть когда мы занимаемся разработкой?

Мы определяем слои приложения. Определяем контракты взаимодействия между слоями и разбиваем приложение на модули. Давайте попробуем применить эти инструменты и здесь.

Слои

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

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

Декомпозиция

Большие задачи нужно разделять на маленькие. Маленькая задача — это задача максимум на пару дней.

ТЗ

Всем известно выражение: Без внятного ТЗ — результат ХЗ.

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

В любой нормальной компании ТЗ является обязательным элементом к задаче. Правда это касается только крупных задач.

Казалось бы что ТЗ вполне похоже на контракт в контексте программирования. Какие я вижу проблемы с ТЗ:

1. Для большой задачи будет ТЗ страниц на 400 и более, которое у программиста в голове целиком не поместится. Я начинаю засыпать на десятой странице.
2. Для средней задачи будет ссылка на раздел или пункт в ТЗ. Тогда программист только этот пункт и прочитает. Потом конечно выяснится, что один маленький пункт в другом разделе ТЗ кардинально изменяет всю реализацию
3. Для небольшой задачи, которая идет в рамках поддержки, ТЗ вовсе не будет.
4. ТЗ не всегда однозначно трактуется сторонами процесса разработки. И все что может быть понято неправильно — будет именно неправильно и понято.

Тут видно, что ТЗ явно недостаточно. Возникает вопрос что же делать?

Критерии приемки

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

Можем ли мы применять тесты и в нашей практике? Да мы и так все тестируем и даже в описании процесса это есть, скажет внимательный читатель. Да, но нет. Я говорю немного о другом тестировании.

Тестирование в описанном выше процессе заключается в ручной проверке соответствия результата поставленному ТЗ. Каждый участник такого тестирования, ознакомившись с ТЗ, как-то его интерпретирует в собственную картину. Проблема в том, что у всех получается разная картина. Человек неидеальный интерпретатор. Нужно скомпилировать ТЗ в бинарник один раз. Не интерпретировать много раз и по-разному. А один раз и на “бумагу”. В результате должен появится некий набор артефактов. Это могут быть тест-кейсы или критерии приемки.

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

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

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

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

Возражения

Предвижу вопрос от менеджеров:

Разработка критериев приемки занимает дополнительное время. Где же его взять?

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

А вы все равно разрабатываете критерии приемки. Причем не один раз. При подготовке ТЗ какие-то критерии приемки возникают в голове у аналитика и заказчика. При постановке задачи происходит то же самое. Программист формирует их у себя в голове. В момент сдачи задачи на любом из этапов выполняется тот же процесс. Но ни на одном из этапов не появилось никакого артефакта. Вот и вся разница.

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

Смею вас заверить, что разработка критериев приемки окупается сторицей.

Результат

Как изменяется процесс после внедрения критериев приемки наравне с ТЗ?

Программист делает свою работу в соответствии с критериями приемки. Менеджер принимает работу. Затем то же самое делает и Заказчик. И у него нет повода не оплатить эту задачу.

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

А что на этот счет думаете Вы?