Человечная декомпозиция работы

Декомпозирование личностями для личностей

Person Concerned Work Decomposition (PСWD)

About me

Alexander Petrov (a.k.a Lysenko)

Pragmatic Programmer | Sing, Play Sax & Guitar | #Emacs #Clojure #Datomic #DDD #TDD #CleanArchitecture

Старший разработчик Clojure Центра продуктов Дозор в Ростелеком Солар

2015 - 2022 Старший разработчик Ruby / Rails / Erlang в FunBox

2006 - 2014 Enterprise Java Developer / Trainer / Architect / Team Leader / Lecturer

Структура

• История про программиста-перфекциониста и тимлида его - оптимиста (Отсылка к Радио-Т и Пушкину А.С.)

• Состояние “Потока”, в чем его ценность и как создать условия для его возникновения?

• От #микротаскинга до #NoEstimates, как найти разумный баланс и не впасть в крайности?

• Декомпозиция с ориентацией на работника-личность - вот ответ! Что это и как этого достичь?

• Cтратегии приближения к человечной декомпозиции

История ПП. Бизнес 1/10

Есть продукт по тарифицированию коммерческого СМС трафика

Компании шлют информационные и рекламные СМС

Чтобы СМС стоила дешевле компании регистрируют имена отправителей (короткие номера)

Для ещё меньшей цены заводят шаблоны текста на подобие: “Покупка, карта *{d4}. {d} RUB … и т.д.”

История ПП. Программист прагматик 2/10

Есть начитанный программист перфекционист (ПП)

10+ лет опыта и 3 года на проекте

Относится к проекту как к своему дому на всю жизнь

Это лучший проект, в котором он участвовал

Болезненно воспринимает срезание углов

Добивается высокого качества и ждёт того же от команды

История ПП. Тимлидер оптимист 3/10

Есть новый самоуверенный тимлидер оптимист (ТО)

Это самый крупный проект для него

Обязанностей так много, что нет возможности погружаться в код

Он недооценивает сложность доработок 2,5 раза в среднем

Сам декомпозирует, проектирует фичи и ставит сроки

E.g., в одну задачу кладёт создание модели, в другую её UI

ПП переделывает декомпозицию не щадя живота своего

Программисты следуют плану и долго борются с тех. долгом

История ПП. Антагонизм ПП и ТО 4/10

Где у ПП “ВЫКЛ”, у ТО - “ВКЛ” (c) Большая разница

ПП начитанный практик, фанат DDD, ТО - практик “от сохи” больше тяготеющий к SRE, чем к бизнес-логике

ПП перезакладывается, ТО недозакладывается

ПП хорошо знаком с проектом, ТО - поверхностно

ПП слишком радеет за качество, ТО - удивляет менеджмент низкими прогнозами и требует срезать углы

Между ПП и ТО - как будто несоответствие импеданса. ПП перегревается. (Аналогия: усилитель мощности и динамик)

История ПП. Новая фича 5/10

Есть списки стоп-слов по тематикам для блокировки трафика

Нужно блокировать шаблоны для определённой тематики слов

Какая это тематика - коммерческая тайна, но это не важно

Если шаблон заблокирован, то он не участвует в тарификации

А значит цена за СМС получается выше, как за рекламу

История ПП. Декомпозиция ТО 6/10

ТО разделил решение задачи внутри алгоритма на двух человек

Каждый делает сервисный объект формирующий вспомогательные выборки данных по шаблонам и блокировкам (Деталей не помню и они не важны)

Один использует сервисные объекты для сборки алгоритма

История ПП. Результат 7/10

Разработчики испытывают дискомфорт целую неделю, но уверены, что всё сделали правильно и в срок

Ручные тестировщики обнаруживают фатальный недостаток:

При появлении нового стоп-слова в тематике для шаблонов

соответствующие шаблоны блокируются

При удалении стоп-слова из тематики или из самого шаблона

соответствующие шаблоны не разблокируются хотя должны

История ПП. Анализ 8/10

10% функциональности реализовано

Все всё сделали как было спроектировано

Никто не видел общей картины и не мог предвидеть ошибку

ПП предчувствовал некорректность декомпозиции

Были жесткие сроки и было решено для эксперимента действовать по плану

История ПП. Исправление 9/10

ПП сверхурочно работает, чтобы успеть исправить алгоритм, до того, как ТО станет требовать объяснений почему нельзя исправить в рамках изначального дизайна и сохранить статус-кво

Нужна жёсткая аргументация в виде рабочего и наглядного решения

ПП делает сервисный объект который вычисляет и блокировки, и разблокировки

В этом сервисном объекте кешируется нужная информация и решение получается простым и оптимальным

История ПП. Выводы 10/10

Выводы из этой истории привели к экстрагированию мыслительного процесса ПП при проектировании и к формулировке советов по декомпозиции

Нельзя разделять фичу внутри границ алгоритма между исполнителями (9 женщин не родят ребёнка за месяц)

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

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

Состояние потока

Механизмы работы мозга

Быстрый, автоматический - не затратный, может подводить

Медленный, аналитический - высоко затратный, позволяет получать более взвешенные решения

Исключение - состояние потока

Результативность и концептуальная целостность (качество) результата в состоянии потока недостижимы без этого состояния

В состоянии потока открывается доступ к смётке

Смётка

Смётка - (в специальном смысле) способность ментально представлять функционирование конкретного или абстрактного механизма и находить решения для его исправления или усовершенствования

Что истощает смётку?

Переключение контекста, суета, отсутствие автоматизации и навыков

Что восстанавливает?

Интерес, созерцание и уединение

#HammockMode #Рыбалка #Физкультура #ЗанятияМузыкой

Закон Паркинсона

Работа заполняет время, отпущенное на неё

1955 - Сирил Норткот Паркинсон. Сатирическая статья о бюрократии.

Менеджмент индустрии ПО ошибочно взял на вооружение этот неуместный для креативной деятельности “закон”.

#микротаскинг

Веря в “закон” Паркинсона можно дойти до решения “проблем” с человеческой природой через #микротаскинг

Бесчеловечный подход, характерный для работы крупных капиталистических производств

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

• О целостности заботятся “Архитекторы” (авторитеты), которые знают, как все фичи поделить на атомы, чтобы обезличенные люди-роботы их выполняли

#NoEstimates

Если понимать ценность потока и сметки то можно стараться каждую фичу делать целиком, не давая никаких оценок.

Предварительные оценки не нужны! Работа будет сделана тогда, когда будет достигнуто концептуально целостное решение. А случится это всё равно это быстрее, чем мы закончим оценивать.

#NoEstimates может не сработать

No Estimates может не сработать, если хотя бы один пункт выполняется (расположены в порядке влияния и распространённости):

• используются мейнстримовые технологии с посредственной продуктивностью из-за accidental complexity

• команды не состоят из “10X” программистов

• стейкхолдеры нуждаются в ориентировочных сроках (B2B, B2C, Digital с нуждой в маркетинге и рекламе)

• кодовая база велика, inherent complexity высока и любое изменение требует больших затрат времени

Декомпозиция работы ради проектирования

Кто нам “мешает”, тот нам поможет! (с) Кавказская пленница

Слона нужно есть по частям (c) народная мудрость

Даже если кажется, что это Моська (c) добавил от себя

Декомпозировать работу полезно для фокусировки мыслительного процесса

Свойства человечной декомпозиции 1/2

Каждая задача удовлетворяет следующим критериям:

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

• Задача не превышает 3—5 дней (условно) в предварительной оценке трудозатрат. Это ограничение позволит придать задаче обозримые границы и сделает её управляемой, помещающейся в голове.

Свойства человечной декомпозиции 2/2

Вся совокупность задач должна соответствовать архитектурному принципу Loose Coupling / High Cohesion (Слабая зависимость / Сильная сплочённость), а именно:

• Loose Coupling: Зависимости между задачами должны быть минимальными.

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

Проверка декомпозиции

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

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

Вопросы к задаче

• Можно ли целостно думать о задаче в изоляции от других задач?

• Можно ли вынести из задачи что-то лишнее так, чтобы при этом не нарушилась целостность?

• Не слишком ли мала задача? Не должна ли она быть частью какой-то большей задачи, чтобы та была целостной?

Вопросы к совокупности задач

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

• Являются ли все задачи управляемыми по объёму (оценка не превышает 3—5 дней)?

• Не слишком ли мелко разбиты задачи и не нарушена ли их целостность?

Стратегии декомпозиции

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

1. Отказ от декомпозиции

Декомпозиция - не должна быть бременем, она должна быть помощником

Обозримые фичи можно не делить на части и выполнять одним куском

На маленьком масштабе затраты на декомпозицию могут быть потерей ресурсов

2. Делегирование исполнителю

// Поподробнее почему иногда неудачно делать декомопзицию самому тимлиду.

Тим лид не должен делать декомпозицию всех фич, спуская сверху конкретные задачи

Тим лид должен помогать своим разработчикам совершать декомпозицию

Нужно выбирать главного исполнителя на фичу

Он вникнет в требования и сделает декомпозицию на набор комфортных задач себе и коллегам - помощникам.

3. Отказ от детального проектирования

Фича - кусок мрамора

Отрезать куски по границам, которые проявляются на этапе предварительного проектирования

Отказываться детально проектировать

Ошибка преждевременного детального проектирования может парализовать исполнителя и сделать его несчастным

4. Группировка функциональности

по сходному уровню сложности, неопределённости или риска

5. Поэтапная декомпозиция

Большие фичи и связанные наборы фич не нужно декомпозировать наперёд целиком

Откладывайте решения до последнего момента, когда их совершенно необходимо принять

Так вы будете обладать максимально доступной информацией для принятия решения

И минимизируете ущерб от неудачных преждевременных решений

6. Выделение смыслового ядра

смысловое ядро и второстепенные механизмы

Метафора “Хирург и команда ассистентов” (c) Фред Брукс

7. Выделение прототипа 1/3

Если после выделения смыслового ядра оно остаётся достаточно большим и неуправляемым по трудозатратам,

и не очевидно, как разделить его на подзадачи управляемого размера,

можно выделить несколько дней на прототипирование и остальное время оставить на реализацию продуктовой версии фичи

7. Выделение прототипа 2/3

После прототипирования может возникнуть идея разделения на подзадачи

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

7. Выделение прототипа 3/3

По Фреду Бруксу вторая версия системы всегда лучше первой

Прототип это первая версия системы в миниатюре

Нас не парализует необходимость сделать всё сразу и не ниже уровня нашего внутреннего стандарта

Прототип идёт в корзину, но позволяет реализовать вторую версию как следует, ибо мозг потренировался в безопасном режиме

Итоги 1/3

Отчуждение смысла от разработчика ->

Отсутствие концептуальной целостности ->

Вечно растущий технический долг (accidental complexity) ->

Дороговизна сопровождения ->

Посредственные результаты ->

Профессиональное выгорание

Итоги 2/3

Свобода и комфорт разработчика ->

Состояние потока ->

Активизация смётки ->

Наличие концептуальной целостности ->

Низкая accidental complexity ->

Низкая совокупная стоимость владения ->

Выдающиеся результаты бизнеса ->

Низкая текучка кадров

Итоги 3/3

Концептуальная целостность (низкая accidental complexity) роскошь?

Для аутсорсингового бизнеса, к сожалению, чаще непозволительная роскошь.

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

Успешной всем нам декомпозиции работы!

История ПП. Долгосрочный результат

Человечная декомпозиция стала частью регламента разработки

ТО перестал за разработчиков делать декомпозицию

ТО стал заниматься стратегическими улучшениями архитектуры DataPipeline и инфраструктуры проекта

ТО смог разрабатывать фичи для поддержания формы

ПП стал добиваться высокого качества без ущерба здоровью

Стажёр стал миддлом не меняя работу благодаря ЧеДеР

Источники 1/2

• Дейв Томас и Энди Хант «Программист прагматик. Путь от подмастерья к мастеру».
• Фред Брукс «Мифический человеко-месяц».
• Эрик Эванс «Предметно-ориентированное проектирование (DDD). Структуризация сложных программных систем».
• Том ДеМарко и Тимоти Листер «Человеческий фактор. Успешные проекты и команды».

Источники 2/2

• Мери и Том Поппендик «Бережливое производство программного обеспечения. От идеи до прибыли».
• Даниэль Каннеман Thinking Fast And Slow.
• Роберт Пирсиг «Дзен и искусство ухода за мотоциклом», в особенности рассуждения автора о смётке и вещах, которые её истощают. Я и само это слово узнал из книги.

БОНУС. Неконструктивные убеждения о людях 1/2

Следующие 6 убеждений о человеческой природе не конструктивно класть в основу управления креативной деятельностью, в особенности созданием ПО

• Человек от природы порочен, и только давление общества заставляет его сдерживать свои порывы.

• Человек ленив, и его нужно заставлять работать, иначе он будет прокрастинировать.

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

БОНУС. Неконструктивные убеждения о людях 2/2

• Человеком движет жажда материальных ценностей для себя (эгоизм и алчность).

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

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

Спасибо за внимание

Подробнее тема раскрывается в моей статье на Хабре Человечная декомпозиция работы

ВОПРОСЫ?

ДОПОЛНЕНИЯ?