Данный тред подсветил важный аспект. Даже если мы находимся в ситуации, когда требуется более высокая прозрачность процесса разработки за счет более мелкого дробления на задачи, важно чтобы это дробление делал сам исполнитель. Я предполагаю, что в подходе Никиты большинство задач будет больше 15 минут, и даже больше 1 часа, в отличие от подхода микротаскинга, который я привёл как экстремальный, когда большинство задач не будет превышать получаса и постановка будет делаться другим обезличенным разработчиком. Важно, что оплата в подходе Никиты делается не за каждую задачу, а за осмысленный целостный результат.
Повышенная прозрачность процесса в случае Никиты требуется из-за того, что есть заказчики или менеджмент, которые не слишком погружены в специфику и проблемы разработки. Проекты делаются для внешних заказчиков, которые жёстко спрашивают о затратах.
Благо в команде все разработчики уровня senior с высокой продуктивностью и сознательностью. Даже за 15 минут они могут разработать что-то существенное, готовое к выпуску в продакшн.
У нас в FunBox немного другая ситуация для разработчиков. Мы разрабатываем долгоживущие в нашей инфраструктуре продукты для заказчика, полностью на нашей поддержке. Этих продуктов много и разработчики в командах долго бывают привязаны к одному проекту. Разработчики чувствуют долгосрочную заинтересованность в качестве ибо им этот код и сопровождать. Так как проектов много, мы не можем работать только с senior-ами. Типичная команда состоит из профессионалов с разным опытом, и младшим разработчикам оказывается поддержка. Менеджмент, силами технического руководства, хорошо осведомлён о сложности разработки и доверяет командам. Всё это приводит к тому, что прозрачность снаружи не требуется, и деление на задачи можно осуществлять только в интересах разработчика. Это позволяет для новых фич не создавать задач размером меньше двух часов. Понимается, что если фича новая, то всегда вылезет что-то над чем нужно подумать. Нужно посмотреть как подобные вещи сделаны в кодовой базе для единого стиля, исследовать требования.
На мой взгляд подход Никиты соответствует идеям человечной декомпозиции, в контексте фирмы разработчика заказных продуктов, командой из 10 высококлассных профессионалов.
Я рекомендую доклад Никиты [[https://sobolevn.me/talks/teamleadconf-2020][Practical Microtasks]] в качестве дополнения. Всё практики, о которых Никита рассказывает мы применяем в FunBox, с тем отличием, что большинство проектов у нас на Elixir, Erlang и Ruby, а не Python. Хотя Python тоже используем в DataScience области.
Обсудив в ЛС, мы с Никитой решили, что в статью излишне добавлять это разъяснение. Достаточно сделать его в виде данного комментария.
Плюсую всё сказанное в статье! У меня подобные мысли всегда были, но так хорошо я бы не написал. Большое спасибо, fillpackart, за труд!
Забавное совпадение! Я тоже на первой стажировке писал программу для игры в шахматы с интерфейсом под Windows на C++ MFC. На этой задаче очень хорошо было отрабатывать умение разделять бизнес логику и логику отображения, а так же осваивать ООП. Угрохал кучу времени, но это было чрезвычайно полезно.
Недавно у меня вышла статья по схожей проблематике. Человечная декомпозиция работы
Я рассматривю, помимо прочего, психологические проблемы разработчика, вызываемые некачественной декомпозицией задач, и даю рекомендации по улучшению ситуации.
Заранее благодарю за внимание!
Ещё раз благодарю за вклад в улучшение статьи. Упомянул Вас в changelog.
Моя странная особенность в том, что я никогда не встречал книг, которые бы отталкивались от обозначенных убеждений о человеческой природе как истинных. Видимо это эффект склонности к подтверждению своей точки зрения (confirmation bias). Хотя статей, опирающихся на полезность отталкивания от закона Паркинсона, встречал много в ИТ сфере. И очень мало статей с ним не соглашающихся.
Мне было бы полезно узнать о таких книгах, которые Вам попадались и опирались на истинность данных убеждений.
Хотя, возможно, я Вас не так понял, и Вы находите непоследовательным лишь ход моих рассуждений, который не достаточно обосновывает мои советы.
Описание контекста я тоже вынашиваю. Спасибо Вам за вдохновение!
Огромное спасибо, Никита, за пояснение и шикарный доклад!
Я понял в чем отличие твоего подхода от Zerocracy, и почему он гораздо ближе к моей концепции человечности изложенной в статье.
Я обязательно добавлю раздел с разъяснением этого различия, чтобы не возникало негативного отношения к микротаскам в более широком смысле, чем это обозначено в экстремальном подходе Zerocracy.
По части микротаскинга. В статье я говорю о ситуации доведения размера задачи до абсолютного минимума, которая пропагандируется Zerocracy. Мне показалось уместным при обсуждении моего подхода показать от чего в пределе я хочу предостеречь людей. Однажды во время уборки дома мне пришла эта идея с континуумом стилей декомпозиции от экстремально мелких задач, до отсутствия очерчивания границ задач совсем. Меня всегда волновал вопрос внутреннего неприятия подхода Zerocracy и я решил свои мысли органично вплести в своё эссе.
Очевидно ты говоришь совсем не о таком отчуждающем микротаскинге, раз результат задачи попадает на прод и приносит удовлетворённость исполнителю. Твой подход в этом континууме находится ближе к моему. Я бы его назвал минитаскингом. Полагаю, люди в подразумеваемом тобой подходе не говорят: «Я не ассоциирую себя с результатом моего труда, я его полностью отчуждаю»? У них сохраняется профессиональная гордость за результат труда как это было с ремесленниками до возникновения капитализма.
Опишу типичный контекст, в котором мой подход возник. Я говорю о разработке некоей новой большой бизнес-фичи дней на 10—12 разработки в предварительной оценке, допустим, с несколькими экранами, хранимыми моделями, алгоритмом вычисления чего-нибудь и рассылкой результатов вычисления куда-то.
И я утверждаю, что мне комфортно разрбатывать её целиком, отдавая разве что какие-то второстепенные механизмы помощникам, чтобы разгрузить голову. Создавая для себя подзадачи с целостными границами, которые помогают мне строить мыслительный процесс. Я испытываю паралич, если эти границы провёл за меня кто-то другой и выставил срок. Даже при том, что официально нас за непопадание в срок никто не наказывает, мой внутренний критик требует, чтобы я в сроки попадал, и это меня тоже парализует.
Пример с OpenSource понятен и хорош, но и в OpenSource не все проекты могут разрабатываться большим числом людей небольшими приращениями. Бывает проекты требующие целостного подхода какого-то единого мыслителя носителя видения. Я имею в виду точку зрения Рича Хикки. Всё зависит от характера проекта. Сложно делать обобщения.
>> Команды должны состоять из небольшого числа самомотивированных и высокопродуктивных профессионалов.
> Имея такую вводную, можно использовать почти любую организацию процесса. Хоть листочки на доске, хоть микро-таски, хоть #NoEstimates. Людям главное не мешать.
Это справедливо. Я лишь подчеркнул, что для #NoEstimates это условие является необходимым, а для других более распространенных ситуаций можно справляться, имея смешанную команду разработчиков разного уровня. Но чтобы при этом получать качественный результат нужно делегировать им декомпозицию и обучать их этому.
> В итоге, можно сказать, что к счастью ведут разные дороги. Главное, понимать, по какой нужно идти именно тебе.
Совершено согласен. Надеюсь моя дорога, будучи извлеченной из моей интуиции и описанной, станет ещё одной альтернативой для людей.
Было бы интересно узнать больше о твоей системе микротаскинга, например, в сравнении с Zerocracy, так как меня эта тема по настоящему трогает.
Спасибо за дельную статью, ViKt0R-K! Очень понравилось обилие конкретных примеров. Это даёт ценную пищу для размышлений.
Моя точка зрения на освещенные вопросы созвучна Вашей.
Проблема декомпозиции для меня оказалась ключевым интересом в профессии.
Этот интерес привёл меня к написанию статьи habr.com/ru/post/524678/
В особенности я акцентирую внимание на трудностях выбора размера задач и характере зависимостей между ними.
Моя статья находится на уровне управления разработкой. Предполагается, что на входе требования к фичам, прошедшие декомпозицию на уровне бизнес аналитики. Ваша статья больше касается вопросов первичной декомпозиции потребностей бизнеса. Было приятно обнаружить, что есть недавняя статья, которая, как бы, дополняет мою статью.
В конце моей статьи волнующий меня опрос про отношение к закону Паркинсона.
Мне интересно Ваше мнение и мнение читателей Вашей статьи.
Плюсую за защиту состояния потока у программиста. В компании FunBox, где я работаю, мы к этому стремимся. Во многом помогает ориентация на полностью удалённую работу, когда все коммуникации ведутся максимально асинхронно.
Мне удалось вырабоать подход к декомпозиции работы, при котором оценки служат лишь инструментом проектирования, но не инструментом отвлечения программиста от работы и наказания за непопадание в них. Мне кажется, что мы нашли разумный баланс. Я описал этот подход в статье habr.com/ru/post/524678/#MercyfulDecomposition
Будет очень интересно узнать Ваше, nmivan, мнение и мнение читателей Вашей статьи.
Ключевой пункт, в котором мы с Вами расходимся, это отношение к закону Паркинсона.
Я считаю его неуместным в отношении креативной деятельности.
Когда возникает впечатление, что в конкретной ситуации закон сработал, то это нужно рассматривать как несчастный случай, а не закономерность. Я рассматриваю это как иллюзию.
В статье я более развернуто об этом пишу в разделе habr.com/ru/post/524678/#AboutBoundaries
После статьи есть голосование о законе Паркинсона.
Благодарю за хороший вопрос, jimni! Действительно, важно для себя ли делаются оценки.
Я добавляю слово «предварительная», чтобы сделать акцент на её неокончательности и условности. Эта оценка нужна не для менеджмента, чтобы наказать исполнителя или оценщика в случае непопадания. Она нужна для самого человека, занимающегося декомпозицией, чтобы грубо оценивать задачи и от чего-то отталкиваться. Возможно, лучше было бы использовать более абстрактные оценки в условных попугаях. Эти оценки больше нужны для соотнесения задач в декомпозиции относительно друг друга, чтобы можно было отвечать на контрольные вопросы об их качествах.
У нас в компании оценки делаются в днях для того чтобы не усложнять процесс вводом дополнительных абстрактных единиц. При этом всем участникам дают понять, что не уложиться в оценку это абсолютно нормально. Желательно проанализировать причину непопадания и попытаться скорректировать свой «глазомер» на будущее, если это вообще возможно в условиях огромного разнообразия задач и обстоятельств.
После перехода на человечную декомпозицию, получается так, что основной исполнитель по фиче занимается декомпозицией. Ключевые задачи по смысловому ядру он берёт себе и оценки он делает для себя. Вспомогательные задачи он делает на помощников в этой фиче, желательно, спрашивая у них оценку или предлагая согласовать свою. При этом оценки не влияют ни на какие KPI.
Весь процесс декомпозиции ведётся в трекере и наблюдать за ним могут все участники команды, находя и предлагая возможности для улучшения. Если декомпозицию проводит сотрудник с небольшим опытом в этих делах, то ему более активно помогают выделенные для этого коллеги. Сначала сотрудник описывает в виде комментария совокупность задач, не создавая настоящих задач. Так удобнее вносить изменения и видеть общую картину.
Благодарю за обратную связь iiopy4uk_mck! Она даёт пищу для размышлений и улучшения статьи.
Если я правильно понял Вашу мысль, то в статье не хватает обоснования ложности приведённых убеждений, ибо без них не понятно почему мой подход к декомпозиции лучше других подходов.
Год назад, будучи в самом начале пути познания философии, я думал, что могу пытаться обосновывать ложность этих убеждений на основе идей гуманизма, единственного, что я успел познать. github.com/alexpetrov/humanistic-work-decomposition
Но теперь я считаю, что я не достаточно компетентен, чтобы замахиваться на эту задачу. Вместо этого я предлагаю каждому человеку искать эти ответы самостоятельно, обращаясь к философским трудам, и, заглядывая внутрь себя, как критерий истины.
Кроме того, статься стала бы совершенно невменяемой по размеру и фокусировке.
Единственное, что мне следует уточнить в статье, что ложными эти убеждения становятся, когда претендуют на всеобщность, в то время как они являются просто распространёнными, но частными случаями. Порождаются они неблагоприятными обстоятельствами жизни большинства людей.
Спорность моего подхода неизбежна, ибо он требует повышенных душевных усилий и слабо поддаётся наукообразному обоснованию. Но мне он помог радикально улучшить рабочую ситуацию, только поэтому я им делюсь, в надежде, что он поможет кому-то ещё.
Благодарю за теплые слова и очень уместный вопрос, HuckF1nn. Рад, что статья оказалась интересной и созвучной Вам.
Сложность в том, чтобы не впадать в крайности, а находить баланс.
Речь идёт о том, чтобы не все, но некоторые фичи, как правило не самые сложные, отдавать джуниорам, в качестве «хирургов».
Физически невозможно было бы отдавать все фичи джунам, ибо им нужно оказывать огромную поддержку.
Фичи бывают разными по уровню сложности, определённости и риска. Некоторые нужно обязательно отдавать сеньёрам.
Если найти баланс, то и конфликта интересов не будет. Старшие разработчики будут в достаточной степени удовлетворять и технические амбиции, и прокачивать софт скилы человеческого общения и менторства.
Важно, чтобы джунам не доставались только задачи из категории второстепенных механизмов, или задачи спущенные сверху с готовой жёсткой формулировкой «как делать?» и жёстким сроком, вместо «какую проблему нужно решить?».
Кстати, на мой взгляд, один из признаков достижения истинного уровня сеньёрности заключается в том, что уже не достаточно делать что-то очень круто своими руками, но возникает потребность делиться мастерством с другими.
Конфликт интересов скорее может возникать на уровне мидлов.
Вероятно, мне стоит поставить этот акцент на балансе в статье. Добавлю эту идею себе. Огромное спасибо!
Простых советов здесь быть не может. Радует, что ситуация на рынке труда создаёт для программистов условия, в которых работодатели вынуждены заботиться об истинном развитии сотрудников, пусть и ценой бОльших усилий и непростых решений. В противном случае мы наблюдаем текучку. То есть с трудом набранные люди занимаются бессмысленными на их уровне задачами, не приносят тот value, который могли бы, не растут, страдают и быстро уходят.
Не исключено, что я живу в «пузыре» и неадекватно оцениваю тенденции рынка. Но хочется верить, что всё близко к описанному.
Я ответил на вопросы? Или лучше сделать это по обозначенным пунктам?
Статья задумана как самодостаточная и не предполагает продолжения. Хотя обратная связь может привести к идеям развития.
У меня возникла мысль о написании выжимки из статьи с сокращением количества рассуждений. Только голые советы, просто для шпаргалки.
Правильно я понимаю, что у Вас есть впечатление, что конструктива в статье недостаточно, либо что он погребен под объёмом текста и до него сложно добраться?
Благодарю JustDont, за такой развернутый и содержательный комментарий.
Мой основной посыл в том, что я вижу причину некачественного процесса декомпозиции, и как следствие низкого качества программных продуктов, в ложных убеждениях о человеческой природе. Первые 4 или часть из них могут заставлять ориентироваться на закон Паркинсона.
Я стремлюсь переломить эту распространенную ситуацию, предложив подход, исходящий из того, что люди могут быть и не такими. Стоит попробовать им доверять, и тогда, возможно, они раскроются, качество их работы улучшится, и они воспрянут духом. В результате и текучка может снизиться.
Ваши мысли созвучны моим. По пунктам:
1. Я не утверждаю, что ложные убеждения свойственны все в совокупности и всем людям на управляющих позициях. Интересно, что даже сами исполнители могут верить в эти убеждения, ухудшая этим жизнь на своём месте. Подумаю как сформулировать в статье свою мысль лучше.
2 и 3. Всё верно, и именно с этим явлением «закатывания частного общим» я веду борьбу. Благодарю за это разъяснение. Возможно оно позволит мне улучшить статью.
Интересно узнать Ваше мнение по основной части статьи, начиная с раздела «Человечная декомпозиция».
Этот комментарий должен был быть ответом на комментарий habr.com/ru/post/524678/#comment_22216000, но я промахнулся, а удалять комментарии нельзя.
Прошу вести дискуссию в рамках правильной ветки.
Благодарю JustDont, за такой развернутый и содержательный комментарий.
Мой основной посыл в том, что я вижу причину некачественного процесса декомпозиции, и как следствие низкого качества программных продуктов, в ложных убеждениях о человеческой природе. Первые 4 или часть из них могут заставлять ориентироваться на закон Паркинсона.
Я стремлюсь переломить эту распространенную ситуацию, предложив подход, исходящий из того, что люди могут быть и не такими. Стоит попробовать им доверять, и тогда, возможно, они раскроются, качество их работы улучшится, и они воспрянут духом. В результате и текучка может снизиться.
Ваши мысли созвучны моим. По пунктам:
1. Я не утверждаю, что ложные убеждения свойственны все в совокупности и всем людям на управляющих позициях. Интересно, что даже сами исполнители могут верить в эти убеждения, ухудшая этим жизнь на своём месте. Подумаю как сформулировать в статье свою мысль лучше.
2 и 3. Всё верно, и именно с этим явлением «закатывания частного общим» я веду борьбу. Благодарю за это разъяснение. Возможно оно позволит мне улучшить статью.
Интересно узнать Ваше мнение по основной части статьи, начиная с раздела «Человечная декомпозиция».
Действительно эти книги я читал больше десяти лет назад, и не сомневаюсь, что идеи NoEstimates там содержатся. Именно поэтому они в своё время могли лечь в подготовленную почву, когда возникло обсуждение на конференции.
Я лишь говорю о моменте, когда эти идеи популяризировались через возникновение хештега #NoEstimates в Твиттере, породив новую волну обсуждений. Для статьи этот хештег оказался ёмким и популярным термином для обозначения ситуации с вырожденной декомпозицией, как противоположность экстремальной декомпозиции в микротаскинге.
Действительно, стоит перечитать эти книги, и переписать данный раздел с ссылкой на них, как более основательные источники. Это может улучшить статью. Благодарю за совет!
Благодарю за положительный отзыв, sshikov.
То о чём Вы говорите, это не принципы, а свойства человечной декомпозиции, к которым нужно стремиться. В следующем разделе «Верефикация декомпозиции» я добавляю конструктива. Я пишу о том, как итеративно с помощью контрольных вопросов к каждой задаче, и ко всей совокупности задач, можно достигнуть декомпозиции, которая будет иметь шансы на обладание таким качеством. А в разделе «Стратегии декомпозиции» я даю рецепты, как сделать это с меньшим количеством итераций и с чего начать.
Прошу Вас уточнить критику, если и в этих разделах конструктива окажется недостаточно. Это поможет улучшить статью.
Насчет квалификации и обучения, полностью согласен. Именно это мы и стараемся делать, пользуясь стратегией назначения главным исполнителем по некоторым фичам самого младшего разработчика в команде, делегируя ему процесс декомпозиции и оказывая ему поддержку со стороны умных, как Вы говорите, людей. Когда удаётся это делать — это самый благодатный опыт для меня!
Совершенно согласен! В проекте такого характера нужны решения с большей дисциплиной, и облегченный сценарий с выносом в скрипты в задачах совсем не годится.
В таком проекте подошёл бы подход с гемом для миграций данных в стиле миграций схемы. Либо можно продолжать использовать миграции схемы для миграций данных, если связанные с этим проблемы не сильно актуальны в силу масштаба.
Данный тред подсветил важный аспект. Даже если мы находимся в ситуации, когда требуется более высокая прозрачность процесса разработки за счет более мелкого дробления на задачи, важно чтобы это дробление делал сам исполнитель. Я предполагаю, что в подходе Никиты большинство задач будет больше 15 минут, и даже больше 1 часа, в отличие от подхода микротаскинга, который я привёл как экстремальный, когда большинство задач не будет превышать получаса и постановка будет делаться другим обезличенным разработчиком. Важно, что оплата в подходе Никиты делается не за каждую задачу, а за осмысленный целостный результат.
Повышенная прозрачность процесса в случае Никиты требуется из-за того, что есть заказчики или менеджмент, которые не слишком погружены в специфику и проблемы разработки. Проекты делаются для внешних заказчиков, которые жёстко спрашивают о затратах.
Благо в команде все разработчики уровня senior с высокой продуктивностью и сознательностью. Даже за 15 минут они могут разработать что-то существенное, готовое к выпуску в продакшн.
У нас в FunBox немного другая ситуация для разработчиков. Мы разрабатываем долгоживущие в нашей инфраструктуре продукты для заказчика, полностью на нашей поддержке. Этих продуктов много и разработчики в командах долго бывают привязаны к одному проекту. Разработчики чувствуют долгосрочную заинтересованность в качестве ибо им этот код и сопровождать. Так как проектов много, мы не можем работать только с senior-ами. Типичная команда состоит из профессионалов с разным опытом, и младшим разработчикам оказывается поддержка. Менеджмент, силами технического руководства, хорошо осведомлён о сложности разработки и доверяет командам. Всё это приводит к тому, что прозрачность снаружи не требуется, и деление на задачи можно осуществлять только в интересах разработчика. Это позволяет для новых фич не создавать задач размером меньше двух часов. Понимается, что если фича новая, то всегда вылезет что-то над чем нужно подумать. Нужно посмотреть как подобные вещи сделаны в кодовой базе для единого стиля, исследовать требования.
На мой взгляд подход Никиты соответствует идеям человечной декомпозиции, в контексте фирмы разработчика заказных продуктов, командой из 10 высококлассных профессионалов.
Я рекомендую доклад Никиты [[https://sobolevn.me/talks/teamleadconf-2020][Practical Microtasks]] в качестве дополнения. Всё практики, о которых Никита рассказывает мы применяем в FunBox, с тем отличием, что большинство проектов у нас на Elixir, Erlang и Ruby, а не Python. Хотя Python тоже используем в DataScience области.
Обсудив в ЛС, мы с Никитой решили, что в статью излишне добавлять это разъяснение. Достаточно сделать его в виде данного комментария.
Плюсую всё сказанное в статье! У меня подобные мысли всегда были, но так хорошо я бы не написал. Большое спасибо, fillpackart, за труд!
Забавное совпадение! Я тоже на первой стажировке писал программу для игры в шахматы с интерфейсом под Windows на C++ MFC. На этой задаче очень хорошо было отрабатывать умение разделять бизнес логику и логику отображения, а так же осваивать ООП. Угрохал кучу времени, но это было чрезвычайно полезно.
Недавно у меня вышла статья по схожей проблематике.
Человечная декомпозиция работы
Я рассматривю, помимо прочего, психологические проблемы разработчика, вызываемые некачественной декомпозицией задач, и даю рекомендации по улучшению ситуации.
Заранее благодарю за внимание!
Буду признателен за обратную связь по этим двум изменениям вдохновлённым Вами.
Моя странная особенность в том, что я никогда не встречал книг, которые бы отталкивались от обозначенных убеждений о человеческой природе как истинных. Видимо это эффект склонности к подтверждению своей точки зрения (confirmation bias). Хотя статей, опирающихся на полезность отталкивания от закона Паркинсона, встречал много в ИТ сфере. И очень мало статей с ним не соглашающихся.
Мне было бы полезно узнать о таких книгах, которые Вам попадались и опирались на истинность данных убеждений.
Хотя, возможно, я Вас не так понял, и Вы находите непоследовательным лишь ход моих рассуждений, который не достаточно обосновывает мои советы.
Описание контекста я тоже вынашиваю. Спасибо Вам за вдохновение!
Я понял в чем отличие твоего подхода от Zerocracy, и почему он гораздо ближе к моей концепции человечности изложенной в статье.
Я обязательно добавлю раздел с разъяснением этого различия, чтобы не возникало негативного отношения к микротаскам в более широком смысле, чем это обозначено в экстремальном подходе Zerocracy.
По части микротаскинга. В статье я говорю о ситуации доведения размера задачи до абсолютного минимума, которая пропагандируется Zerocracy. Мне показалось уместным при обсуждении моего подхода показать от чего в пределе я хочу предостеречь людей. Однажды во время уборки дома мне пришла эта идея с континуумом стилей декомпозиции от экстремально мелких задач, до отсутствия очерчивания границ задач совсем. Меня всегда волновал вопрос внутреннего неприятия подхода Zerocracy и я решил свои мысли органично вплести в своё эссе.
Очевидно ты говоришь совсем не о таком отчуждающем микротаскинге, раз результат задачи попадает на прод и приносит удовлетворённость исполнителю. Твой подход в этом континууме находится ближе к моему. Я бы его назвал минитаскингом. Полагаю, люди в подразумеваемом тобой подходе не говорят: «Я не ассоциирую себя с результатом моего труда, я его полностью отчуждаю»? У них сохраняется профессиональная гордость за результат труда как это было с ремесленниками до возникновения капитализма.
Опишу типичный контекст, в котором мой подход возник. Я говорю о разработке некоей новой большой бизнес-фичи дней на 10—12 разработки в предварительной оценке, допустим, с несколькими экранами, хранимыми моделями, алгоритмом вычисления чего-нибудь и рассылкой результатов вычисления куда-то.
И я утверждаю, что мне комфортно разрбатывать её целиком, отдавая разве что какие-то второстепенные механизмы помощникам, чтобы разгрузить голову. Создавая для себя подзадачи с целостными границами, которые помогают мне строить мыслительный процесс. Я испытываю паралич, если эти границы провёл за меня кто-то другой и выставил срок. Даже при том, что официально нас за непопадание в срок никто не наказывает, мой внутренний критик требует, чтобы я в сроки попадал, и это меня тоже парализует.
Пример с OpenSource понятен и хорош, но и в OpenSource не все проекты могут разрабатываться большим числом людей небольшими приращениями. Бывает проекты требующие целостного подхода какого-то единого мыслителя носителя видения. Я имею в виду точку зрения Рича Хикки. Всё зависит от характера проекта. Сложно делать обобщения.
>> Команды должны состоять из небольшого числа самомотивированных и высокопродуктивных профессионалов.
> Имея такую вводную, можно использовать почти любую организацию процесса. Хоть листочки на доске, хоть микро-таски, хоть #NoEstimates. Людям главное не мешать.
Это справедливо. Я лишь подчеркнул, что для #NoEstimates это условие является необходимым, а для других более распространенных ситуаций можно справляться, имея смешанную команду разработчиков разного уровня. Но чтобы при этом получать качественный результат нужно делегировать им декомпозицию и обучать их этому.
> В итоге, можно сказать, что к счастью ведут разные дороги. Главное, понимать, по какой нужно идти именно тебе.
Совершено согласен. Надеюсь моя дорога, будучи извлеченной из моей интуиции и описанной, станет ещё одной альтернативой для людей.
Было бы интересно узнать больше о твоей системе микротаскинга, например, в сравнении с Zerocracy, так как меня эта тема по настоящему трогает.
Я их покручу в голове и завтра отвечу.
Мне нужно переварить их, и я обязательно отвечу чем-то содержательным.
Моя точка зрения на освещенные вопросы созвучна Вашей.
Проблема декомпозиции для меня оказалась ключевым интересом в профессии.
Этот интерес привёл меня к написанию статьи habr.com/ru/post/524678/
В особенности я акцентирую внимание на трудностях выбора размера задач и характере зависимостей между ними.
Моя статья находится на уровне управления разработкой. Предполагается, что на входе требования к фичам, прошедшие декомпозицию на уровне бизнес аналитики. Ваша статья больше касается вопросов первичной декомпозиции потребностей бизнеса. Было приятно обнаружить, что есть недавняя статья, которая, как бы, дополняет мою статью.
В конце моей статьи волнующий меня опрос про отношение к закону Паркинсона.
Мне интересно Ваше мнение и мнение читателей Вашей статьи.
Заранее благодарю за внимание!
Мне удалось вырабоать подход к декомпозиции работы, при котором оценки служат лишь инструментом проектирования, но не инструментом отвлечения программиста от работы и наказания за непопадание в них. Мне кажется, что мы нашли разумный баланс. Я описал этот подход в статье habr.com/ru/post/524678/#MercyfulDecomposition
Будет очень интересно узнать Ваше, nmivan, мнение и мнение читателей Вашей статьи.
Ключевой пункт, в котором мы с Вами расходимся, это отношение к закону Паркинсона.
Я считаю его неуместным в отношении креативной деятельности.
Когда возникает впечатление, что в конкретной ситуации закон сработал, то это нужно рассматривать как несчастный случай, а не закономерность. Я рассматриваю это как иллюзию.
В статье я более развернуто об этом пишу в разделе habr.com/ru/post/524678/#AboutBoundaries
После статьи есть голосование о законе Паркинсона.
Заранее благодарю за внимание!
Я добавляю слово «предварительная», чтобы сделать акцент на её неокончательности и условности. Эта оценка нужна не для менеджмента, чтобы наказать исполнителя или оценщика в случае непопадания. Она нужна для самого человека, занимающегося декомпозицией, чтобы грубо оценивать задачи и от чего-то отталкиваться. Возможно, лучше было бы использовать более абстрактные оценки в условных попугаях. Эти оценки больше нужны для соотнесения задач в декомпозиции относительно друг друга, чтобы можно было отвечать на контрольные вопросы об их качествах.
У нас в компании оценки делаются в днях для того чтобы не усложнять процесс вводом дополнительных абстрактных единиц. При этом всем участникам дают понять, что не уложиться в оценку это абсолютно нормально. Желательно проанализировать причину непопадания и попытаться скорректировать свой «глазомер» на будущее, если это вообще возможно в условиях огромного разнообразия задач и обстоятельств.
После перехода на человечную декомпозицию, получается так, что основной исполнитель по фиче занимается декомпозицией. Ключевые задачи по смысловому ядру он берёт себе и оценки он делает для себя. Вспомогательные задачи он делает на помощников в этой фиче, желательно, спрашивая у них оценку или предлагая согласовать свою. При этом оценки не влияют ни на какие KPI.
Весь процесс декомпозиции ведётся в трекере и наблюдать за ним могут все участники команды, находя и предлагая возможности для улучшения. Если декомпозицию проводит сотрудник с небольшим опытом в этих делах, то ему более активно помогают выделенные для этого коллеги. Сначала сотрудник описывает в виде комментария совокупность задач, не создавая настоящих задач. Так удобнее вносить изменения и видеть общую картину.
Постараюсь сделать шпаргалку.
Пока в качестве выжимки предлагаю часть текста презентации предыдущего доклада: github.com/alexpetrov/humanistic-work-decomposition#%D0%B3%D1%83%D0%BC%D0%B0%D0%BD%D0%B8%D1%81%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B0%D1%8F-%D0%B4%D0%B5%D0%BA%D0%BE%D0%BC%D0%BF%D0%BE%D0%B7%D0%B8%D1%86%D0%B8%D1%8F
Если я правильно понял Вашу мысль, то в статье не хватает обоснования ложности приведённых убеждений, ибо без них не понятно почему мой подход к декомпозиции лучше других подходов.
Год назад, будучи в самом начале пути познания философии, я думал, что могу пытаться обосновывать ложность этих убеждений на основе идей гуманизма, единственного, что я успел познать. github.com/alexpetrov/humanistic-work-decomposition
Но теперь я считаю, что я не достаточно компетентен, чтобы замахиваться на эту задачу. Вместо этого я предлагаю каждому человеку искать эти ответы самостоятельно, обращаясь к философским трудам, и, заглядывая внутрь себя, как критерий истины.
Кроме того, статься стала бы совершенно невменяемой по размеру и фокусировке.
Единственное, что мне следует уточнить в статье, что ложными эти убеждения становятся, когда претендуют на всеобщность, в то время как они являются просто распространёнными, но частными случаями. Порождаются они неблагоприятными обстоятельствами жизни большинства людей.
Спорность моего подхода неизбежна, ибо он требует повышенных душевных усилий и слабо поддаётся наукообразному обоснованию. Но мне он помог радикально улучшить рабочую ситуацию, только поэтому я им делюсь, в надежде, что он поможет кому-то ещё.
Сложность в том, чтобы не впадать в крайности, а находить баланс.
Речь идёт о том, чтобы не все, но некоторые фичи, как правило не самые сложные, отдавать джуниорам, в качестве «хирургов».
Физически невозможно было бы отдавать все фичи джунам, ибо им нужно оказывать огромную поддержку.
Фичи бывают разными по уровню сложности, определённости и риска. Некоторые нужно обязательно отдавать сеньёрам.
Если найти баланс, то и конфликта интересов не будет. Старшие разработчики будут в достаточной степени удовлетворять и технические амбиции, и прокачивать софт скилы человеческого общения и менторства.
Важно, чтобы джунам не доставались только задачи из категории второстепенных механизмов, или задачи спущенные сверху с готовой жёсткой формулировкой «как делать?» и жёстким сроком, вместо «какую проблему нужно решить?».
Кстати, на мой взгляд, один из признаков достижения истинного уровня сеньёрности заключается в том, что уже не достаточно делать что-то очень круто своими руками, но возникает потребность делиться мастерством с другими.
Конфликт интересов скорее может возникать на уровне мидлов.
Вероятно, мне стоит поставить этот акцент на балансе в статье. Добавлю эту идею себе. Огромное спасибо!
Простых советов здесь быть не может. Радует, что ситуация на рынке труда создаёт для программистов условия, в которых работодатели вынуждены заботиться об истинном развитии сотрудников, пусть и ценой бОльших усилий и непростых решений. В противном случае мы наблюдаем текучку. То есть с трудом набранные люди занимаются бессмысленными на их уровне задачами, не приносят тот value, который могли бы, не растут, страдают и быстро уходят.
Не исключено, что я живу в «пузыре» и неадекватно оцениваю тенденции рынка. Но хочется верить, что всё близко к описанному.
Я ответил на вопросы? Или лучше сделать это по обозначенным пунктам?
У меня возникла мысль о написании выжимки из статьи с сокращением количества рассуждений. Только голые советы, просто для шпаргалки.
Правильно я понимаю, что у Вас есть впечатление, что конструктива в статье недостаточно, либо что он погребен под объёмом текста и до него сложно добраться?
Мой основной посыл в том, что я вижу причину некачественного процесса декомпозиции, и как следствие низкого качества программных продуктов, в ложных убеждениях о человеческой природе. Первые 4 или часть из них могут заставлять ориентироваться на закон Паркинсона.
Я стремлюсь переломить эту распространенную ситуацию, предложив подход, исходящий из того, что люди могут быть и не такими. Стоит попробовать им доверять, и тогда, возможно, они раскроются, качество их работы улучшится, и они воспрянут духом. В результате и текучка может снизиться.
Ваши мысли созвучны моим. По пунктам:
1. Я не утверждаю, что ложные убеждения свойственны все в совокупности и всем людям на управляющих позициях. Интересно, что даже сами исполнители могут верить в эти убеждения, ухудшая этим жизнь на своём месте. Подумаю как сформулировать в статье свою мысль лучше.
2 и 3. Всё верно, и именно с этим явлением «закатывания частного общим» я веду борьбу. Благодарю за это разъяснение. Возможно оно позволит мне улучшить статью.
Интересно узнать Ваше мнение по основной части статьи, начиная с раздела «Человечная декомпозиция».
Прошу вести дискуссию в рамках правильной ветки.
Благодарю JustDont, за такой развернутый и содержательный комментарий.
Мой основной посыл в том, что я вижу причину некачественного процесса декомпозиции, и как следствие низкого качества программных продуктов, в ложных убеждениях о человеческой природе. Первые 4 или часть из них могут заставлять ориентироваться на закон Паркинсона.
Я стремлюсь переломить эту распространенную ситуацию, предложив подход, исходящий из того, что люди могут быть и не такими. Стоит попробовать им доверять, и тогда, возможно, они раскроются, качество их работы улучшится, и они воспрянут духом. В результате и текучка может снизиться.
Ваши мысли созвучны моим. По пунктам:
1. Я не утверждаю, что ложные убеждения свойственны все в совокупности и всем людям на управляющих позициях. Интересно, что даже сами исполнители могут верить в эти убеждения, ухудшая этим жизнь на своём месте. Подумаю как сформулировать в статье свою мысль лучше.
2 и 3. Всё верно, и именно с этим явлением «закатывания частного общим» я веду борьбу. Благодарю за это разъяснение. Возможно оно позволит мне улучшить статью.
Интересно узнать Ваше мнение по основной части статьи, начиная с раздела «Человечная декомпозиция».
Действительно эти книги я читал больше десяти лет назад, и не сомневаюсь, что идеи NoEstimates там содержатся. Именно поэтому они в своё время могли лечь в подготовленную почву, когда возникло обсуждение на конференции.
Я лишь говорю о моменте, когда эти идеи популяризировались через возникновение хештега #NoEstimates в Твиттере, породив новую волну обсуждений. Для статьи этот хештег оказался ёмким и популярным термином для обозначения ситуации с вырожденной декомпозицией, как противоположность экстремальной декомпозиции в микротаскинге.
Действительно, стоит перечитать эти книги, и переписать данный раздел с ссылкой на них, как более основательные источники. Это может улучшить статью. Благодарю за совет!
То о чём Вы говорите, это не принципы, а свойства человечной декомпозиции, к которым нужно стремиться. В следующем разделе «Верефикация декомпозиции» я добавляю конструктива. Я пишу о том, как итеративно с помощью контрольных вопросов к каждой задаче, и ко всей совокупности задач, можно достигнуть декомпозиции, которая будет иметь шансы на обладание таким качеством. А в разделе «Стратегии декомпозиции» я даю рецепты, как сделать это с меньшим количеством итераций и с чего начать.
Прошу Вас уточнить критику, если и в этих разделах конструктива окажется недостаточно. Это поможет улучшить статью.
Насчет квалификации и обучения, полностью согласен. Именно это мы и стараемся делать, пользуясь стратегией назначения главным исполнителем по некоторым фичам самого младшего разработчика в команде, делегируя ему процесс декомпозиции и оказывая ему поддержку со стороны умных, как Вы говорите, людей. Когда удаётся это делать — это самый благодатный опыт для меня!
В таком проекте подошёл бы подход с гемом для миграций данных в стиле миграций схемы. Либо можно продолжать использовать миграции схемы для миграций данных, если связанные с этим проблемы не сильно актуальны в силу масштаба.