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

img


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


Определения

Фича (feature) — бизнес-возможность, автоматизируемая в программном продукте. Это англицизм, который широко применяется в ИТ-индустрии. Я не нашёл для него хорошего русского аналога.


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


Смётка — способность человека строить в уме модель функционирования механизма или природного явления, предсказывать поведение и находить причины неполадок посредством сосредоточенного усилия и интуиции. Это определение соответствует пониманию из книги «Дзен и искусство ухода за мотоциклом» и уточняет более общее значение из словаря: способность быстро соображать, рассчитывать.


Более 5 лет я работаю бэкенд-разработчиком в FunBox. В компании мы считаем, что хорошие продукты — результат развитой инженерной культуры и стремимся практиковать этот принцип в разработке решений для мобильных операторов. Тут есть свои особенности стека и процессов, но есть и универсальные аспекты, применимые в любой предметной области. Один из них — подход к декомпозиции. Благодаря продуктовому характеру работы и инженерной культуре мне удалось получить опыт и озарения, о которых я не могу молчать.


Навигация по статье:



Контекст



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


К своим озарениям я пришёл в рамках разработки B2B продукта, находящегося в промышленной эксплуатации. Абстрактно обрисую типичную фичу. Допустим, фича будет содержать бизнес-агрегат из пары моделей (сущностей), для которого нужно реализовать экраны создания, редактирования, просмотра и удаления. Ещё нужно реализовать алгоритм вычисления чего-то связанного с этим бизнес-агрегатом, а результат вычислений отправить на email. Предполагается, что сверху фича оценена хотя бы 10-12 дней. В ней достаточно пространства для творческого осмысления и проектирования. Команда состоит из профессионалов разного уровня от младшего до старшего. Команда включет тимлида, который стремится в том числе заниматься кодированием, чтобы не терять ощущение профессии, продукта и сохранять внутреннюю мотивацию. За границами команды никого не интересует как происходит процесс разработки, и никто в него не вмешивается. По крайней мере пока всё в порядке.


Народная мудрость гласит: «слона нужно есть по частям». Полезно разделить разработку всей фичи на задачи меньшего размера, чтобы снизить риски, сфокусировать усилия и повысить управляемость процесса. Я расскажу как я это делаю, как к этому пришёл, и от чего ушёл. Последнее для меня наиболее важно.


Ложные убеждения о человеческой природе



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


  1. Человек от природы порочен, и только давление общества заставляет его сдерживать свои порывы.
  2. Человек ленив, и его нужно заставлять работать, иначе он будет прокрастинировать.
  3. Человек склонен до бесконечности улучшать любой достаточно хороший результат, даже если это не несёт никакой ценности заинтересованным лицам (перфекционизм).
  4. Человеком движет жажда материальных ценностей для себя (эгоизм и алчность).
  5. Человек нуждается в подчинении и в том, чтобы ему подчинялись (авторитаризм).
  6. Человек не любит людей и стремится избегать взаимодействия с ними в процессе решения рабочих и жизненных задач (мизантропия).

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


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


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


Отступление. Направления поиска более реалистичных взглядов на человека и мир

Агностикам в вопросе существования высших сил может быть ближе миросозерцание гуманистов, например Эриха Фромма. Я попытался кратко сформулировать своё понимание миросозерцания гуманистов в докладе «Гуманистическая декомпозиция работы».


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


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


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


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


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


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



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


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

Это «Первый закон Паркинсона», который в 1955 году сформулировал историк Сирил Норткот Паркинсон в сатирической статье на основе наблюдений за британской бюрократией. К сожалению, эта сатира очень быстро распространилась и стала универсальным законом. Даже менеджмент в индустрии программного обеспечения взял его на вооружение, стал тиражировать и бороться с его проявлениями.


В книге «Человеческий фактор. Успешные проекты и команды» Том ДеМарко и Тимоти Листер обосновывают неприменимость этого закона к людям, занимающимся креативной деятельностью, в противоположность серийному промышленному производству и бюрократии. Здесь и далее я ставлю название закона в кавычки, чтобы подчеркнуть отношение к нему как к ложному утверждению в контексте, отличном от описания бюрократии.


Континуум стилей декомпозиции



Стили декомпозиции работы лежат в континууме:


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

Микротаскинг



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


  • Если человек ленив (ложное убеждение № 2), то задания нужно делать максимально мелкими, чтобы не было возможности ни минуты сфилонить и получить оплату за прокрастинацию.


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


  • Если человеком движет эгоизм и жажда материальных ценностей, то и работодатель и работник должны максимизировать свою выгоду и минимизировать потери. Нужно платить только за сделанные атомарные задания, устанавливая такую цену, чтобы она достаточно удовлетворяла потребности работника и стимулировала его больше работать без прокрастинации, но и без достаточного погружения в смысл. Чтобы делить работу над фичей на мелкие задания по 10—15 минут, нужны некие архитекторы. Они должны обладать авторитетом, и исполнители будут им с радостью подчиняться, ибо испытывают в этом потребность (ложное убеждение № 5).



Это устройство производственного процесса очень напоминает конвейер, на котором рабочие могут выполнять незатейливые, изолированные операции, не требующие ни большой квалификации, ни взаимодействия с другими людьми. Ещё Карл Маркс в 1840-х и Эрих Фромм в 1960-х годах описали такое устройство производства и экономические причины его существования. Также они описали, насколько губительно и невыносимо это для человека. Участвуя в производстве такого характера, человек теряет связь с результатами своего труда, отчуждается от них. Для человека исчезает смысл в его деятельности, он ощущает подавленность и тревогу. Всё это ведёт к раннему профессиональному выгоранию и более тяжёлым последствиям.


Когда все задачи мелкие, то постоянно приходится переключать контекст внимания. Переключение контекста требует от мозга больших энергозатрат (об этом хорошо написано в книге Thinking Fast And Slow). Это огромный источник потерь для смётки. Ослабление смётки приводит к ошибкам. При микротаскинге нет места для восстановления мыслительных ресурсов, или, как это ёмко называет Максим Дорофеев, мыслетоплива. Забота об этом ложится на плечи работника.


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


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


NoEstimates



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


Я узнал об этой концепции из доклада Асхата Уразбаева на AgileDays'14. Основными условиями для достижения ситуации, когда не возникает необходимости в оценках, Асхат называет следующие:


  1. Непрерывная доставка ценности заказчику.
  2. Отсутствие зависимостей, которые могут что-то сломать. Для обеспечения этого свойства нужен налаженный процесс непрерывной интеграции (CI) с междукомандными интеграционными тестами.
  3. Уравновешивание возможностей, то есть пропускной способности команды, и потребностей заказчика.

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


  1. Используются выдающиеся, не мейнстримовые технологии, дающие радикальный прирост продуктивности.
  2. Команды состоят из небольшого числа самомотивированных и высокопродуктивных профессионалов.
  3. Продукт вовлекает своих воплотителей настлько, что они сами предугадывают нужные фичи или реализовывают запрошенную стейкхолдерами функциональность за меньшее время, чем отнял бы процесс оценки и планирования.

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


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


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



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


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



При человечной декомпозиции каждая задача удовлетворяет следующим критериям:


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

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


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


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



Замечание о характере зависимостей

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


Зависеть же от ещё не разработанных сервисных объектов крайне дискомфортно. Я бы советовал рассматривать зависимости между задачами по API сервисных объектов как decomposition smell (термин аналогичен code smell), то есть маркер низкого качества декомпозиции.


Верификация декомпозиции



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


Контрольные вопросы к каждой задаче:


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

Контрольные вопросы к совокупности задач:


  1. Нет ли между задачами слишком сильных зависимостей, возможно, неявных, в особенности если они даются разным исполнителям?
  2. Являются ли все задачи управляемыми по объёму (оценка не превышает 3—5 дней)?
  3. Не слишком ли мелко разбиты задачи и не нарушена ли их целостность?

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


Обоснование выбранной цифры для границы размеров задач



3—5 дней — цифра условная. Граница размера задачи, которая помещается в голове, будет зависеть от сложности технологии. Данную цифру я привожу для проекта на Ruby on Rails.


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


Многих такая большая цифра может тревожить, если они склонны соглашаться c «законом Паркинсона». Я встречал два вида опасений, связанных с этим законом:


  1. Человек будет прокрастинировать (ложное убеждение № 2) всё время, которое ему выделят на работу, и под конец срока в авральном режиме сделает халтурное решение.
  2. Человек быстро сделает всё, что нужно, но так как ещё остаётся время, то он из перфекционизма (ложное убеждение № 3) будет заниматься ненужными улучшениями решения вместо того, чтобы перейти к следующей задаче.

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


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


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


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


Примеры нарушения целостности задач и ощущения исполнителей



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


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



Предположим, что реализуемая фича требует наличия сущности с персистентным хранением (модель в терминах Ruby on Rails) и CRUD пользовательского интерфейса для неё.
Напрашивающимся решением по декомпозиции будет завести задачу на реализацию модели и на реализацию пользовательского интерфейса, её использующего.


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


Пример ошибки раздельного проектирования модели и пользовательского интерфейса в проекте на Ruby on Rails

В Ruby on Rails удобно делать группу чекбоксов для множественного выбора через связь «многие-ко-многим». Это так называемая has_and_belongs_to_many HABTM-связь между двумя моделями без отдельной модели для связующей таблицы.
Если рассматривать модель без учёта пользовательского интерфейса, то все знают, что HABTM-связь использовать не рекомендуется. Она выбрасывает модель связи, у которой могут появиться свои поля и поведение. Считается, что проектировщик может срезать углы, используя HABTM-связь, потому что не хочет задумываться о связующей модели как о сущности, имеющей собственную идентичность и состояние. Никто не хочет использовать не рекомендуемые приёмы. Но ситуация, когда связь нужна исключительно для выражения множественного выбора в веб UI, является исключением из правила. В этом случае искусственное введение связующей модели будет перебором и нарушением принципа «Бритва Оккама», то есть внесением сущностей сверх необходимого для объяснения явления или его моделирования.


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


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


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


Разделение внутри алгоритма



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


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

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


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


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


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


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


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


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



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


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



Если слово «декомпозиция» воспринимать буквально как разделение на части, то может показаться, что на выходе этого процесса должно обязательно получаться больше одной задачи.
Одна задача, даже большая, вполне может быть результатом процесса декомпозиции.
Если фича недостаточно велика и верхнеуровнево оценена в 3—5 дней, то может так случаться, что дальнейшее деление не даст преимуществ, но может создать проблемы, если ошибиться в границах задач. В особенности, если дать их разным исполнителям в надежде выполнить работу быстрее.


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



У тимлида может сложиться ложное впечатление, что в его обязанности входит выполнение всех декомпозиций и спуск задач сверху членам команды разработки. Так может случиться, если в должностной инструкции не донести мысль, что от тимлида требуется обеспечить процесс декомпозиции, а не выполнить её самому. Ещё это впечатление может сложиться из ложного убеждения № 5, что человек нуждается в подчинении и чтобы ему подчинялись. Если же постановку задач делегировать их исполнителю, то никакой власти у тимлида не останется, никакого авторитета не будет и подчиняться ему как следует не смогут, при том что нуждаются в этом.


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


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


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


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


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


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


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


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


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



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


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


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


4. Группировка функциональности по сходному уровню сложности, неопределённости или риска



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


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


Если внутри задачи есть пункты с разными уровнями по этим свойствам, то с такой задачей можно застрять, при том что некоторые части уже готовы и их можно было бы продвинуть по конвейеру создания ценности. Это увеличивает объем незавершённой работы — W.I.P. (work in progress). Эмоциональное самочувствие исполнителя ухудшается, потому что на него давит этот незавершённый гештальт.


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



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


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


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



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


Эти концепты я почерпнул из главы 15 «Дистилляция» книги Эрика Эванса «Предметно-ориентированное проектирование (DDD). Структуризация сложных программных систем». Для простоты рассуждений я объединил неспециализированные подобласти (Generic Subdomains) и связные механизмы (Cohesive Mechanisms), от которых очищается смысловое ядро (Core Domain), в категорию второстепенных механизмов.


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


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


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


Во времена, которые описывает Фред Брукс, системы были больше и обладали огромной случайной сложностью (accidental complexity) из-за неразвитости технологий и железа. Фичи были огромными, а итерации очень длинными.


Но стоит пойти дальше, ведь сейчас типичные бизнес-приложения разрабатываются небольшими приращениями, укладывающимися в итерации длиной от двух до четырёх недель. Технологии скрывают значительную часть сложности за абстракциями. Особенно в этом преуспевают omakase-фреймворки, в частности Ruby On Rails и подобные ему.


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


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


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


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



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


Можно поделить в пропорции «золотого сечения», когда меньшая часть времени отдаётся на прототип, можно поделить и в отношении 1:3. Но важно выделять на прототип достаточно времени, чтобы не ощущалось чрезмерное давление. Лучше по факту закончить прототипирование чуть раньше — тогда больше времени останется на продуктовую версию.


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


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


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


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


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


Практика создания прототипов подробно описана в книге Дейва Томаса и Энди Ханта «Программист прагматик. Путь от подмастерья к мастеру» в 1999 году. Ещё раньше, в 1975 году, Фред Брукс описал подобную практику создания опытных систем в книге «Мифический человеко-месяц».


Приведу яркую цитату из Главы 11 «Планируйте на выброс» для тех, кто скептически относится к прототипам:


Поэтому планируйте выбросить первую версию — вам всё равно придётся это сделать.

От прецедента к должностной инструкции



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


Уже полтора года мы в команде осознанно применяем обозначенные в статье приёмы. Это дало тимлиду возможность не заниматься постоянно декомпозицией работы для других, а производить инновации: существенно улучшить архитектуру работы с логами, мониторингом и многими другими общими инфраструктурными механизмами. Тимлид смог поучаствовать в качестве основного разработчика в создании нескольких бизнес-фич. Младший разработчик смог сделать то же самое. Он получил драйв, самостоятельность и в результате вырос до мидла. Я сам стал работать ещё комфортнее, чем до изменений. Другие команды стали применять человечную декомпозицию и рассказали мне о положительном опыте.


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


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


Источники



Прийти к идеям человечной декомпозиции мне помогли следующие книги:


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

Найти более глубокое обоснование идеям человечной декомпозиции и опровергнуть заблуждения о человеческой природе мне помогли эти книги (большинство из них есть в аудио):


  1. Все книги Эриха Фромма.
  2. Николай Бердяев все книги, в особенности: «Смысл творчества. Опыт оправдания человека», «О назначении человека. Опыт парадоксальной этики» и финальная «Царство Духа и Царство Кесаря».
  3. Кен Уилбер «Благодать и стойкость. Духовность и исцеление в истории жизни и смерти Трейи Киллам Уилбер».
  4. Даниэль Каннеман Thinking Fast And Slow.
  5. Роберт Пирсиг «Дзен и искусство ухода за мотоциклом», в особенности рассуждения автора о смётке и вещах, которые её истощают. Я и само это слово узнал из книги.

Направления дальнейшего моего поиска:


  1. Клер Уильям Грейвз «Спиральная динамика». Первый раз услышал о спиральной динамике от Максима Цепкова на конференции AgileDays'14, кстати, тогда же, когда и про #NoEstimates. Это знание сильно повлияло на меня.
  2. Кен Уилбер «Интегральный подход». У Уилбера много книг. Я только начал их изучение но кажется, его миросозерцание созвучно Николаю Бердяеву и потому интересно, до каких озарений дошёл современный нам человек, интересующийся широким спектром вопросов философии, психологии, духовности и науки.

Changelog



Благодарю всех комментаторов за вклад в улучшение содержания статьи!


UPDATE 2020-10-27 Уточнение формулировки понятия о ложности убеждений о человеческой природе


Благодаря комментариям @JustDont и @iiopy4uk_msk мне удалось улучшить формулировку моего утверждения о ложности растиражированных убеждений о человеческой природе. А именно проблема возникает, когда описанные частные случаи поведения считаются общезначимыми свойствами человеческой природы, и от этого выстраивается априорная защита даже в креативных видах бизнеса. Это же относится и к «закону Паркинсона», согласие с которым может вытекать из данного обобщения.


UPDATE 2020-10-27 Добавление описания контекста, в котором выкристализовались идеи


После опубликования статьи я стал смотреть, что ещё пишут про декомпозицию, и оказалось, что она бывает на разных уровнях. Есть декомпозиция уровня бизнес-анализа, когда выясняется какие есть у бизнес проблемы и как их разбить на независимые фичи. А есть декомпозиция уровня разработки, когда уже от уровня бизнес-анализа поступили разумные готовые истории на разработку. При этом не исключается, что на уровне разработки станет понятно, что эти требования нужно вернуть на доработку аналитикам. Статья фокусируется на проблеме декомпозиции работы по реализуемым разумным требованиям.


Так же @iiopy4uk_msk указал на полезность обозначения контекста для лучшего понимания подхода. Эти размышления привели к добавлению раздела Контекст. В нём я привёл описание типа продукта, типичной фичи, состава команды разработчиков и её отношений с внешним миром.


UPDATE 2020-11-20 Устное обсуждение статьи в сообществе DevOps Moscow


Статья заинтересовала Александра Титова и он пригласил меня обсудить её в сообществе DevOps Moscow. Я с самого начала существования этого сообщества с февраля 2013 года являюсь его участником. Мне очень понравился этот отпыт. Участники своими вопросами и мнениями помогли раскрыть содержание и ключевые идеи статьи. Смотреть запись трансляции советую только на повышенной скорости, потому что я разговариваю медленно и долго подбираю подходящие слова.
Благодарю Александра Титова и участников сообщества за общение!

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

Что вы думаете о применимости закона Паркинсона в сфере разработки ПО? (Прошу тех, кто выберет вариант, что ни один из ответов не подходит, поделиться в комментариях своим отношением к закону Паркинсона. Возможно, какие-то из Ваших вариантов я добавлю в опрос.)

  • 7,4%Закон Паркинсона работает. Человек будет всё отведённое на задачу время прокрастинировать и в последний момент сделает всё кое-как.4
  • 3,7%Закон Паркинсона работает. Человек будет всё отведённое на задачу время заниматься ненужными улучшениями из-за перфекционизма.2
  • 46,3%Закон Паркинсона работает. И лень, и перфекционизм имееют место в зависимости от ситуации.25
  • 22,2%Закон Паркинсона не работает в отношении креативной деятельности ибо сформулирован для бюрократии и только к ней имеет отношение.12
  • 11,1%Статья склонила меня сменить точку зрения в пользу неприменимости закона Паркинсона.6
  • 9,3%Затрудняюсь ответить. Мне не подходит ни один из вариантов.5

Комментарии 31

    +1
    При человечной декомпозиции каждая задача удовлетворяет следующим критериям:


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

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

    Я для себя сформулировал немного другой человеческий принцип — единственное, что помогает не ошибаться (в том числе при декомпозиции) — это твоя квалификация (или квалификация команды). То есть надо набирать умных людей, а тех кто есть — учить. И учиться.
      0
      Благодарю за положительный отзыв, sshikov.
      То о чём Вы говорите, это не принципы, а свойства человечной декомпозиции, к которым нужно стремиться. В следующем разделе «Верефикация декомпозиции» я добавляю конструктива. Я пишу о том, как итеративно с помощью контрольных вопросов к каждой задаче, и ко всей совокупности задач, можно достигнуть декомпозиции, которая будет иметь шансы на обладание таким качеством. А в разделе «Стратегии декомпозиции» я даю рецепты, как сделать это с меньшим количеством итераций и с чего начать.
      Прошу Вас уточнить критику, если и в этих разделах конструктива окажется недостаточно. Это поможет улучшить статью.

      Насчет квалификации и обучения, полностью согласен. Именно это мы и стараемся делать, пользуясь стратегией назначения главным исполнителем по некоторым фичам самого младшего разработчика в команде, делегируя ему процесс декомпозиции и оказывая ему поддержку со стороны умных, как Вы говорите, людей. Когда удаётся это делать — это самый благодатный опыт для меня!
        0
        Я так понял, будет продолжение?
          0
          Статья задумана как самодостаточная и не предполагает продолжения. Хотя обратная связь может привести к идеям развития.
          У меня возникла мысль о написании выжимки из статьи с сокращением количества рассуждений. Только голые советы, просто для шпаргалки.

          Правильно я понимаю, что у Вас есть впечатление, что конструктива в статье недостаточно, либо что он погребен под объёмом текста и до него сложно добраться?
    0
    #NoEstimates (термин возник из хештега в Твиттере) предполагает, что любая фича в продукте разрабатывается быстрее, чем заинтересованные в ней лица успевают спросить про оценку трудозатрат.


    Мдааааа.
    Как говориться твитер он всему голова.
    А то что это описано тут: Том ДеМарко и Тимоти Листер «Человеческий фактор. Успешные проекты и команды».
    И тут: Фред Брукс «Мифический человеко-месяц».
    Конечно же нет.
    Автор, перечитай книги.
      +3
      Благодарю за комментарий, Mumytroll.

      Действительно эти книги я читал больше десяти лет назад, и не сомневаюсь, что идеи NoEstimates там содержатся. Именно поэтому они в своё время могли лечь в подготовленную почву, когда возникло обсуждение на конференции.
      Я лишь говорю о моменте, когда эти идеи популяризировались через возникновение хештега #NoEstimates в Твиттере, породив новую волну обсуждений. Для статьи этот хештег оказался ёмким и популярным термином для обозначения ситуации с вырожденной декомпозицией, как противоположность экстремальной декомпозиции в микротаскинге.
      Действительно, стоит перечитать эти книги, и переписать данный раздел с ссылкой на них, как более основательные источники. Это может улучшить статью. Благодарю за совет!
      +9
      Товарищи и братья по шахматам, предметом моей сегодняшней лекции служит то, о чем я читал и, должен признаться, не без успеха в Нижнем Новгороде неделю тому назад. Предмет моей лекции — плодотворная дебютная идея. Что такое, товарищи, дебют и что такое, товарищи, идея? Дебют, товарищи, — это quasi una fantasia. А что такое, товарищи, значит идея? Идея, товарищи, — это человеческая мысль, облеченная в логическую шахматную форму. Даже с ничтожными силами можно овладеть всей доской. Все зависит от каждого индивидуума в отдельности.

      (с) Илья Ильф, Евгений Петров, «Двенадцать стульев»
        +3
        Мне видится, что вы начали с немного некорректных посылок.

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

        Во-вторых, проблемы организаций и бюрократий (не только ваша про декомпозицию) вытекают из того, что правила, распространяемые на большое количество людей — всегда отбрасывают все тонкости, детали, и нюансы. Что бы вы не навязали условным 10К человек — для большинства из них это будет «квадратно-гнездовым подходом», не учитывающим конкретику их ситуации. И чем на большее количество людей распространяются правила и принципы — тем более они квадратно-гнездовые. Это конфликт общего и частного.

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

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

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

          Ваши мысли созвучны моим. По пунктам:
          1. Я не утверждаю, что ложные убеждения свойственны все в совокупности и всем людям на управляющих позициях. Интересно, что даже сами исполнители могут верить в эти убеждения, ухудшая этим жизнь на своём месте. Подумаю как сформулировать в статье свою мысль лучше.

          2 и 3. Всё верно, и именно с этим явлением «закатывания частного общим» я веду борьбу. Благодарю за это разъяснение. Возможно оно позволит мне улучшить статью.

          Интересно узнать Ваше мнение по основной части статьи, начиная с раздела «Человечная декомпозиция».
          0
          Этот комментарий должен был быть ответом на комментарий habr.com/ru/post/524678/#comment_22216000, но я промахнулся, а удалять комментарии нельзя.
          Прошу вести дискуссию в рамках правильной ветки.


          Благодарю JustDont, за такой развернутый и содержательный комментарий.

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

          Ваши мысли созвучны моим. По пунктам:
          1. Я не утверждаю, что ложные убеждения свойственны все в совокупности и всем людям на управляющих позициях. Интересно, что даже сами исполнители могут верить в эти убеждения, ухудшая этим жизнь на своём месте. Подумаю как сформулировать в статье свою мысль лучше.

          2 и 3. Всё верно, и именно с этим явлением «закатывания частного общим» я веду борьбу. Благодарю за это разъяснение. Возможно оно позволит мне улучшить статью.

          Интересно узнать Ваше мнение по основной части статьи, начиная с раздела «Человечная декомпозиция».
            0
            Спасибо за статью, очень интересно и оригинальная идея. Хотел бы услышать от Вас ответы на вопросы ниже, учитывая, что модель уже применяете на практике.
            Вот над этим я тоже размышлял, ваша цитата чтобы было понятно о чем я:

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

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


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

            Благодарю за ответы.
              0
              Благодарю за теплые слова и очень уместный вопрос, HuckF1nn. Рад, что статья оказалась интересной и созвучной Вам.

              Сложность в том, чтобы не впадать в крайности, а находить баланс.
              Речь идёт о том, чтобы не все, но некоторые фичи, как правило не самые сложные, отдавать джуниорам, в качестве «хирургов».
              Физически невозможно было бы отдавать все фичи джунам, ибо им нужно оказывать огромную поддержку.
              Фичи бывают разными по уровню сложности, определённости и риска. Некоторые нужно обязательно отдавать сеньёрам.
              Если найти баланс, то и конфликта интересов не будет. Старшие разработчики будут в достаточной степени удовлетворять и технические амбиции, и прокачивать софт скилы человеческого общения и менторства.
              Важно, чтобы джунам не доставались только задачи из категории второстепенных механизмов, или задачи спущенные сверху с готовой жёсткой формулировкой «как делать?» и жёстким сроком, вместо «какую проблему нужно решить?».
              Кстати, на мой взгляд, один из признаков достижения истинного уровня сеньёрности заключается в том, что уже не достаточно делать что-то очень круто своими руками, но возникает потребность делиться мастерством с другими.
              Конфликт интересов скорее может возникать на уровне мидлов.

              Вероятно, мне стоит поставить этот акцент на балансе в статье. Добавлю эту идею себе. Огромное спасибо!

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

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

              Я ответил на вопросы? Или лучше сделать это по обозначенным пунктам?
                0

                Ответили, спасибо.

              +1

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

                +1
                Благодарю за обратную связь iiopy4uk_mck! Она даёт пищу для размышлений и улучшения статьи.

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

                Год назад, будучи в самом начале пути познания философии, я думал, что могу пытаться обосновывать ложность этих убеждений на основе идей гуманизма, единственного, что я успел познать. github.com/alexpetrov/humanistic-work-decomposition

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

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

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

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

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

                    0
                    Благодарю за эти мысли, iiopy4uk_mck!
                    Мне нужно переварить их, и я обязательно отвечу чем-то содержательным.
                      0
                      Ещё раз благодарю за вклад в улучшение статьи. Упомянул Вас в changelog.

                      Моя странная особенность в том, что я никогда не встречал книг, которые бы отталкивались от обозначенных убеждений о человеческой природе как истинных. Видимо это эффект склонности к подтверждению своей точки зрения (confirmation bias). Хотя статей, опирающихся на полезность отталкивания от закона Паркинсона, встречал много в ИТ сфере. И очень мало статей с ним не соглашающихся.

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

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

                      Описание контекста я тоже вынашиваю. Спасибо Вам за вдохновение!
                        0
                        Добавил описание контекста и запись об этом в Changelog.
                        Буду признателен за обратную связь по этим двум изменениям вдохновлённым Вами.
                0
                Предварительная оценка трудозатрат является согласованным значением между какими-то участниками процесса? Или, например, работник назначает её сам себе?
                  0
                  Благодарю за хороший вопрос, jimni! Действительно, важно для себя ли делаются оценки.

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

                  У нас в компании оценки делаются в днях для того чтобы не усложнять процесс вводом дополнительных абстрактных единиц. При этом всем участникам дают понять, что не уложиться в оценку это абсолютно нормально. Желательно проанализировать причину непопадания и попытаться скорректировать свой «глазомер» на будущее, если это вообще возможно в условиях огромного разнообразия задач и обстоятельств.

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

                  Весь процесс декомпозиции ведётся в трекере и наблюдать за ним могут все участники команды, находя и предлагая возможности для улучшения. Если декомпозицию проводит сотрудник с небольшим опытом в этих делах, то ему более активно помогают выделенные для этого коллеги. Сначала сотрудник описывает в виде комментария совокупность задач, не создавая настоящих задач. Так удобнее вносить изменения и видеть общую картину.
                    0
                    Ясно, спасибо
                  +1
                  Александр, привет! Большое спасибо за статью — прочитал с большим удовольствием. Мне особенно нравится, что ты ссылаешься на философию и выстраиваешь цепочки не от бизнеса, а от «духовности». Такой подход мне близок.

                  Как большой фанат и практик микро-таскинга, хочу сделать несколько комментариев. Во-первых, его действительно можно использовать во зло. Если дать нерадивому «менеджеру» (собирательный образ) любой инструмент — он умудрится его испортить. Например тотальным контролем, недоверием, алчностью или глупостью.

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

                  И самый главный мой аргумент:

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

                  Напротив, я вижу и слышу, что люди становятся «счастливы» от такой формы организации работы. Потому что результат видно сразу. Ты сделал что-то – и вот оно! Уже в проде, работает! Еще очень многих мотивирует прозрачность и «понятность» процесса.

                  Я основываю свои практики на том, как ведется разработка в open-source. Где люди *добровольно* организовывают работу похожим образом (с некоторыми допущенями, что open-source пилится урывками раз в неделю перед сном). Вот тут есть хорошее демо: github.com/wemake-services/wemake-python-styleguide Сотни людей, тысячи задачек. Работает как часы. А главное, приносит людям кучу удовольствия. От процесса и результата.

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

                  И последнее:

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

                  Имея такую вводную, можно использовать почти любую организацию процесса. Хоть листочки на доске, хоть микро-таски, хоть #NoEstimates. Людям главное не мешать. Проблема возникает, когда такой вводной нет. А её нет в большом количестве случаев. Что делать в таких случаях – я не знаю.

                  В итоге, можно сказать, что к счастью ведут разные дороги. Главное, понимать, по какой нужно идти именно тебе.
                    +1
                    Привет, Никита! Рад тебя слышать! Огромное спасибо за добрые слова и ценные вопросы!
                    Я их покручу в голове и завтра отвечу.
                      +1
                      Спасибо за этот вклад, Никита!

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

                      Очевидно ты говоришь совсем не о таком отчуждающем микротаскинге, раз результат задачи попадает на прод и приносит удовлетворённость исполнителю. Твой подход в этом континууме находится ближе к моему. Я бы его назвал минитаскингом. Полагаю, люди в подразумеваемом тобой подходе не говорят: «Я не ассоциирую себя с результатом моего труда, я его полностью отчуждаю»? У них сохраняется профессиональная гордость за результат труда как это было с ремесленниками до возникновения капитализма.

                      Опишу типичный контекст, в котором мой подход возник. Я говорю о разработке некоей новой большой бизнес-фичи дней на 10—12 разработки в предварительной оценке, допустим, с несколькими экранами, хранимыми моделями, алгоритмом вычисления чего-нибудь и рассылкой результатов вычисления куда-то.

                      И я утверждаю, что мне комфортно разрбатывать её целиком, отдавая разве что какие-то второстепенные механизмы помощникам, чтобы разгрузить голову. Создавая для себя подзадачи с целостными границами, которые помогают мне строить мыслительный процесс. Я испытываю паралич, если эти границы провёл за меня кто-то другой и выставил срок. Даже при том, что официально нас за непопадание в срок никто не наказывает, мой внутренний критик требует, чтобы я в сроки попадал, и это меня тоже парализует.

                      Пример с OpenSource понятен и хорош, но и в OpenSource не все проекты могут разрабатываться большим числом людей небольшими приращениями. Бывает проекты требующие целостного подхода какого-то единого мыслителя носителя видения. Я имею в виду точку зрения Рича Хикки. Всё зависит от характера проекта. Сложно делать обобщения.

                      >> Команды должны состоять из небольшого числа самомотивированных и высокопродуктивных профессионалов.
                      > Имея такую вводную, можно использовать почти любую организацию процесса. Хоть листочки на доске, хоть микро-таски, хоть #NoEstimates. Людям главное не мешать.

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

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

                      Совершено согласен. Надеюсь моя дорога, будучи извлеченной из моей интуиции и описанной, станет ещё одной альтернативой для людей.

                      Было бы интересно узнать больше о твоей системе микротаскинга, например, в сравнении с Zerocracy, так как меня эта тема по настоящему трогает.
                        +1
                        > У них сохраняется профессиональная гордость за результат труда как это было с ремесленниками до возникновения капитализма.

                        Да! Ровно та идея, которая является для меня ключевой. Когда я начинал, я решил отталкиваться от своих ценностей при построении бизнеса. На вопрос «что же я люблю в своей работе?» — главным ответом было «я люблю писать качественный код». Без данной установки — все остальное вообще не имеет смысла. Следовательно, нам было важно создать такую систему, где данная установка работала бы. От нее отталкиваются все остальные идеи: FFF (мы практикуем активно, без него микро-таски не выходят), полная автоматизация всего (оттуда растет весь наш open-source), DDD и программныые средства выразительности для него (без него вообще ничего не работает).

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

                        > Было бы интересно узнать больше о твоей системе микротаскинга, например, в сравнении с Zerocracy, так как меня эта тема по настоящему трогает.

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

                        Но про свою компанию я рассказываю, как могу: sobolevn.me/talks/teamleadconf-2020
                        Полная коллекция тут: sobolevn.me

                        Для независимого наблюдателя есть возможность сравнить.
                          +1
                          Огромное спасибо, Никита, за пояснение и шикарный доклад!
                          Я понял в чем отличие твоего подхода от Zerocracy, и почему он гораздо ближе к моей концепции человечности изложенной в статье.
                          Я обязательно добавлю раздел с разъяснением этого различия, чтобы не возникало негативного отношения к микротаскам в более широком смысле, чем это обозначено в экстремальном подходе Zerocracy.
                            +1

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


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


                            Благо в команде все разработчики уровня senior с высокой продуктивностью и сознательностью. Даже за 15 минут они могут разработать что-то существенное, готовое к выпуску в продакшн.


                            У нас в FunBox немного другая ситуация для разработчиков. Мы разрабатываем долгоживущие в нашей инфраструктуре продукты для заказчика, полностью на нашей поддержке. Этих продуктов много и разработчики в командах долго бывают привязаны к одному проекту. Разработчики чувствуют долгосрочную заинтересованность в качестве ибо им этот код и сопровождать. Так как проектов много, мы не можем работать только с senior-ами. Типичная команда состоит из профессионалов с разным опытом, и младшим разработчикам оказывается поддержка. Менеджмент, силами технического руководства, хорошо осведомлён о сложности разработки и доверяет командам. Всё это приводит к тому, что прозрачность снаружи не требуется, и деление на задачи можно осуществлять только в интересах разработчика. Это позволяет для новых фич не создавать задач размером меньше двух часов. Понимается, что если фича новая, то всегда вылезет что-то над чем нужно подумать. Нужно посмотреть как подобные вещи сделаны в кодовой базе для единого стиля, исследовать требования.
                            На мой взгляд подход Никиты соответствует идеям человечной декомпозиции, в контексте фирмы разработчика заказных продуктов, командой из 10 высококлассных профессионалов.


                            Я рекомендую доклад Никиты [[https://sobolevn.me/talks/teamleadconf-2020][Practical Microtasks]] в качестве дополнения. Всё практики, о которых Никита рассказывает мы применяем в FunBox, с тем отличием, что большинство проектов у нас на Elixir, Erlang и Ruby, а не Python. Хотя Python тоже используем в DataScience области.


                            Обсудив в ЛС, мы с Никитой решили, что в статью излишне добавлять это разъяснение. Достаточно сделать его в виде данного комментария.

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

                  Самое читаемое