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


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


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


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


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

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


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


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


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


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


Процесс


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


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

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


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


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


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


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


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


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


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


Ассоциации


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


Cхема работы с Заказчиком


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


MVC


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


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

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


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


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


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


Слои


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


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


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


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


ТЗ


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


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


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


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


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

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


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


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


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


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


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


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


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


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


Возражения


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


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


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


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


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


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


Результат


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


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


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


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

Комментарии (14)


  1. EvgeniiR
    06.10.2019 20:25
    +1

    Побуду занудой.


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

    Мне кажется опытный разработчик увидит что в оригинальном MVC пользователь взаимодействует с View а не с Controller, а View в свою очередь зависит от Model(т.к. является активным и сам обновляет себя при обновлении модели), и возможно ещё от контроллера, поэтому ключевая аналогия в статье выглядит весьма неудачно )


    1. aak74 Автор
      06.10.2019 20:38

      Согласно википедии пользователь видит View, а использует Controller, конечно через кнопку во View. Тут Вы правы.
      View не должна зависеть от Model и получает данные от Controller. Тут я являюсь поклонникам Cocoa MVC от Apple.
      image


      1. EvgeniiR
        06.10.2019 20:53

        Согласно википедии

        Согласно Википедии — "Представление (View) отвечает за отображение данных модели пользователю, реагируя на изменения модели[1]."


        Тут я являюсь поклонникам Cocoa MVC от Apple.

        У MVC есть оригинальное определение которое сформировал Трюгве в 1979.
        Более того, ни о каких искаженных определений MVC от Apple я не слышал и Гугл мне в этом не помог.


        1. aak74 Автор
          06.10.2019 20:54

          1. EvgeniiR
            06.10.2019 21:02
            +1

            developer.apple.com/library/archive/documentation/General/Conceptual/DevPedia-CocoaCore/MVC.html

            Ну молодцы ребята, придумали Model-View-Adapter и обозвали это MVC, что ещё сказать?
            Надеюсь что статья отправлена в архив благодаря тому что они получше разобрались в теме.

            Могу дать ссылку от себя на «дефолтное» определение — MVC-originals
            Или вот тут набор ссылок — mvc-index


            1. funca
              07.10.2019 00:00

              Определение Xerox имеет смысл. Правда в том, что после того, как MVC обрел популярность, был определенный период времени, примерно лет 30, когда этими словами называли все, что угодно.


  1. aak74 Автор
    06.10.2019 20:38

    промахнулся ответом


  1. EvgeniiR
    06.10.2019 21:00

    del(Промахнулся веткой).

    Spoiler header
    Хабр после случайной перезагрузки страницы восстановил мой коммент, который был в процессе, но сменил ветку


  1. igor_suhorukov
    06.10.2019 21:09

    Согласен, что нужны приемочные тесты. В которые вовлечён заказчик


  1. VivAmigo
    06.10.2019 21:39
    +1

    Кусочек бреда с юмором от fallout 2 смешанный с обыденностью менеджеров.
    П- программист. М- менеджер.
    П:-Надо критерии приёмки.
    М:-Не критерии приёмки. Техническое задание, да.
    П:-Нет. Критерии приёмки.
    М:-Слу-шай. Критерий приёмки нет. Нет. Совсем нет. Нет критериев. Техническое задание — создали люди-аналитики. Оно описывает всё. Твоя понял?
    П:-НЕТ! НАДО КРИТЕРИИ ПРИЁМКИ!
    М:-НЕТ НИКАКИХ КРИТЕРИЕВ ПРИЕМКИ НА ИСПРАВЛЕНИЕ БАГА, ДУБИНА СТОЕРОСОВАЯ! НЕТ КРИТЕРИЕВ! НЕ СОЗДАВАЛИ! НИКОГДА! НЕТ!
    [КОНЕЦ]
    Ну, а теперь серьёзно. У нас есть аналитики и время им на разработку критериев приёма в виде документации не выделяют от слова «Agile разработка». Так что у нас всё идёт как описано выше. Менеджеры же покрывают «непокрываемое» тестами и работают над тем, что если какой баг появился на боевом — удерживаем клиента в состоянии «Дзен».


  1. Barsik68
    07.10.2019 12:18

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


    1. aak74 Автор
      07.10.2019 12:27

      Это воспитательный процесс?

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


      1. lexxxef
        07.10.2019 23:35

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


  1. valis
    07.10.2019 12:33

    Менеджер это не контроллер. Если переводить на software engenearing это больше напоминает Service registry- Через него обычно не проходят все запросы (иначе бы он загнулся или стал бутылочным горлышком всех процессов). Он знакомит клиента с сервисом компании (точнее с человеком, обеспечивающим этот сервис). А дальше зачастую клиент общается напрямую с этим сервисом.