Comments 31
При человечной декомпозиции каждая задача удовлетворяет следующим критериям:
Ну, хорошие принципы, без дураков. Тут есть только одно но: критерии эти недостаточно конструктивны. То есть, они не позволяют построить декомпозицию, чтобы она сразу была такой как надо. В том числе потому, что у этой задачи нет единственно правильного решения, да и критерии недостаточно четкие (циферки для измерения самодостаточности есть? а нету).
Ну например, задача самодостаточна и целостна. Ну ок, про одну задачу мы это знаем. А про все решение в целом? Достаточно типовой проблемой декомпозиции является та, что человеку свойственно забывать некоторые части решения, необходимые для его функционирования. Особенно — для задач нетиповых, какие вы никогда не решали.
Я для себя сформулировал немного другой человеческий принцип — единственное, что помогает не ошибаться (в том числе при декомпозиции) — это твоя квалификация (или квалификация команды). То есть надо набирать умных людей, а тех кто есть — учить. И учиться.
Благодарю за положительный отзыв, sshikov.
То о чём Вы говорите, это не принципы, а свойства человечной декомпозиции, к которым нужно стремиться. В следующем разделе «Верефикация декомпозиции» я добавляю конструктива. Я пишу о том, как итеративно с помощью контрольных вопросов к каждой задаче, и ко всей совокупности задач, можно достигнуть декомпозиции, которая будет иметь шансы на обладание таким качеством. А в разделе «Стратегии декомпозиции» я даю рецепты, как сделать это с меньшим количеством итераций и с чего начать.
Прошу Вас уточнить критику, если и в этих разделах конструктива окажется недостаточно. Это поможет улучшить статью.
Насчет квалификации и обучения, полностью согласен. Именно это мы и стараемся делать, пользуясь стратегией назначения главным исполнителем по некоторым фичам самого младшего разработчика в команде, делегируя ему процесс декомпозиции и оказывая ему поддержку со стороны умных, как Вы говорите, людей. Когда удаётся это делать — это самый благодатный опыт для меня!
То о чём Вы говорите, это не принципы, а свойства человечной декомпозиции, к которым нужно стремиться. В следующем разделе «Верефикация декомпозиции» я добавляю конструктива. Я пишу о том, как итеративно с помощью контрольных вопросов к каждой задаче, и ко всей совокупности задач, можно достигнуть декомпозиции, которая будет иметь шансы на обладание таким качеством. А в разделе «Стратегии декомпозиции» я даю рецепты, как сделать это с меньшим количеством итераций и с чего начать.
Прошу Вас уточнить критику, если и в этих разделах конструктива окажется недостаточно. Это поможет улучшить статью.
Насчет квалификации и обучения, полностью согласен. Именно это мы и стараемся делать, пользуясь стратегией назначения главным исполнителем по некоторым фичам самого младшего разработчика в команде, делегируя ему процесс декомпозиции и оказывая ему поддержку со стороны умных, как Вы говорите, людей. Когда удаётся это делать — это самый благодатный опыт для меня!
Я так понял, будет продолжение?
Статья задумана как самодостаточная и не предполагает продолжения. Хотя обратная связь может привести к идеям развития.
У меня возникла мысль о написании выжимки из статьи с сокращением количества рассуждений. Только голые советы, просто для шпаргалки.
Правильно я понимаю, что у Вас есть впечатление, что конструктива в статье недостаточно, либо что он погребен под объёмом текста и до него сложно добраться?
У меня возникла мысль о написании выжимки из статьи с сокращением количества рассуждений. Только голые советы, просто для шпаргалки.
Правильно я понимаю, что у Вас есть впечатление, что конструктива в статье недостаточно, либо что он погребен под объёмом текста и до него сложно добраться?
Да, есть такое. Выводы можно бы и обобщить в краткой форме.
Спасибо, Сергей!
Постараюсь сделать шпаргалку.
Пока в качестве выжимки предлагаю часть текста презентации предыдущего доклада: 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#%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
#NoEstimates (термин возник из хештега в Твиттере) предполагает, что любая фича в продукте разрабатывается быстрее, чем заинтересованные в ней лица успевают спросить про оценку трудозатрат.
Мдааааа.
Как говориться твитер он всему голова.
А то что это описано тут: Том ДеМарко и Тимоти Листер «Человеческий фактор. Успешные проекты и команды».
И тут: Фред Брукс «Мифический человеко-месяц».
Конечно же нет.
Автор, перечитай книги.
Благодарю за комментарий, Mumytroll.
Действительно эти книги я читал больше десяти лет назад, и не сомневаюсь, что идеи NoEstimates там содержатся. Именно поэтому они в своё время могли лечь в подготовленную почву, когда возникло обсуждение на конференции.
Я лишь говорю о моменте, когда эти идеи популяризировались через возникновение хештега #NoEstimates в Твиттере, породив новую волну обсуждений. Для статьи этот хештег оказался ёмким и популярным термином для обозначения ситуации с вырожденной декомпозицией, как противоположность экстремальной декомпозиции в микротаскинге.
Действительно, стоит перечитать эти книги, и переписать данный раздел с ссылкой на них, как более основательные источники. Это может улучшить статью. Благодарю за совет!
Действительно эти книги я читал больше десяти лет назад, и не сомневаюсь, что идеи NoEstimates там содержатся. Именно поэтому они в своё время могли лечь в подготовленную почву, когда возникло обсуждение на конференции.
Я лишь говорю о моменте, когда эти идеи популяризировались через возникновение хештега #NoEstimates в Твиттере, породив новую волну обсуждений. Для статьи этот хештег оказался ёмким и популярным термином для обозначения ситуации с вырожденной декомпозицией, как противоположность экстремальной декомпозиции в микротаскинге.
Действительно, стоит перечитать эти книги, и переписать данный раздел с ссылкой на них, как более основательные источники. Это может улучшить статью. Благодарю за совет!
Товарищи и братья по шахматам, предметом моей сегодняшней лекции служит то, о чем я читал и, должен признаться, не без успеха в Нижнем Новгороде неделю тому назад. Предмет моей лекции — плодотворная дебютная идея. Что такое, товарищи, дебют и что такое, товарищи, идея? Дебют, товарищи, — это quasi una fantasia. А что такое, товарищи, значит идея? Идея, товарищи, — это человеческая мысль, облеченная в логическую шахматную форму. Даже с ничтожными силами можно овладеть всей доской. Все зависит от каждого индивидуума в отдельности.
(с) Илья Ильф, Евгений Петров, «Двенадцать стульев»
Мне видится, что вы начали с немного некорректных посылок.
Во-первых, все перечисленные «ложные убеждения» не являются собственно набором убеждений, выражаемых конкретными людьми на управляющих позициях. Какие-то из них конечно же могут выражаться, но едва ли все сразу и всеми без исключения (или хотя бы большинством) управленцев.
Во-вторых, проблемы организаций и бюрократий (не только ваша про декомпозицию) вытекают из того, что правила, распространяемые на большое количество людей — всегда отбрасывают все тонкости, детали, и нюансы. Что бы вы не навязали условным 10К человек — для большинства из них это будет «квадратно-гнездовым подходом», не учитывающим конкретику их ситуации. И чем на большее количество людей распространяются правила и принципы — тем более они квадратно-гнездовые. Это конфликт общего и частного.
В-третьих, частое проявление тех или иных принципов в реальности — обычно вытекает из среднего по социальной группе мнения, а не из частных сильных точек зрения (хотя частные сильные точки зрения на это среднее влияют). То есть, не то, чтоб кто-то прям горой стоял за точку зрения, что все работники во всех ситуациях будут прокрастинировать или страдать перфекционизмом. Но среднее, сложенное из слабых частных (от «мои работники ленивые сволочи» до «мои работники может и норм, но вот Васю и Петю надо контролировать» до «мои работники хороши, но тем не менее совсем немного контроля им не повредит, а мне спокойнее», и эти частные не только от управленцев исходят, но и от самих работников) — оказывается в такой точке, что «Закон Паркинсона» выглядит довольно правдоподобным. А дальше работает то, что было в «во-вторых», и это общее среднее насаждается квадратно-гнездовым способом, даже когда в конкретном случае оно вредит.
И рабочий рецепт против этого собственно очень прост (и часто практикуется, причем не всегда осознанно; вот например тот же аджайл как раз толкает в эту сторону, хотя я не уверен, что авторы манифеста вообще решали проблему конфликта частного и общего): не закатывать частное общим. Когда нет конфликта, то нет и проблем, небольшое количество человек и между собой договорятся, и отторгнут из своей группы мешающих, и горы потом свернут, если не приходить к ним постоянно и не пытаться их взаимодействия уложить в очередную квадратно-гнездовую концепцию наилучшего управления.
Во-первых, все перечисленные «ложные убеждения» не являются собственно набором убеждений, выражаемых конкретными людьми на управляющих позициях. Какие-то из них конечно же могут выражаться, но едва ли все сразу и всеми без исключения (или хотя бы большинством) управленцев.
Во-вторых, проблемы организаций и бюрократий (не только ваша про декомпозицию) вытекают из того, что правила, распространяемые на большое количество людей — всегда отбрасывают все тонкости, детали, и нюансы. Что бы вы не навязали условным 10К человек — для большинства из них это будет «квадратно-гнездовым подходом», не учитывающим конкретику их ситуации. И чем на большее количество людей распространяются правила и принципы — тем более они квадратно-гнездовые. Это конфликт общего и частного.
В-третьих, частое проявление тех или иных принципов в реальности — обычно вытекает из среднего по социальной группе мнения, а не из частных сильных точек зрения (хотя частные сильные точки зрения на это среднее влияют). То есть, не то, чтоб кто-то прям горой стоял за точку зрения, что все работники во всех ситуациях будут прокрастинировать или страдать перфекционизмом. Но среднее, сложенное из слабых частных (от «мои работники ленивые сволочи» до «мои работники может и норм, но вот Васю и Петю надо контролировать» до «мои работники хороши, но тем не менее совсем немного контроля им не повредит, а мне спокойнее», и эти частные не только от управленцев исходят, но и от самих работников) — оказывается в такой точке, что «Закон Паркинсона» выглядит довольно правдоподобным. А дальше работает то, что было в «во-вторых», и это общее среднее насаждается квадратно-гнездовым способом, даже когда в конкретном случае оно вредит.
И рабочий рецепт против этого собственно очень прост (и часто практикуется, причем не всегда осознанно; вот например тот же аджайл как раз толкает в эту сторону, хотя я не уверен, что авторы манифеста вообще решали проблему конфликта частного и общего): не закатывать частное общим. Когда нет конфликта, то нет и проблем, небольшое количество человек и между собой договорятся, и отторгнут из своей группы мешающих, и горы потом свернут, если не приходить к ним постоянно и не пытаться их взаимодействия уложить в очередную квадратно-гнездовую концепцию наилучшего управления.
Благодарю JustDont, за такой развернутый и содержательный комментарий.
Мой основной посыл в том, что я вижу причину некачественного процесса декомпозиции, и как следствие низкого качества программных продуктов, в ложных убеждениях о человеческой природе. Первые 4 или часть из них могут заставлять ориентироваться на закон Паркинсона.
Я стремлюсь переломить эту распространенную ситуацию, предложив подход, исходящий из того, что люди могут быть и не такими. Стоит попробовать им доверять, и тогда, возможно, они раскроются, качество их работы улучшится, и они воспрянут духом. В результате и текучка может снизиться.
Ваши мысли созвучны моим. По пунктам:
1. Я не утверждаю, что ложные убеждения свойственны все в совокупности и всем людям на управляющих позициях. Интересно, что даже сами исполнители могут верить в эти убеждения, ухудшая этим жизнь на своём месте. Подумаю как сформулировать в статье свою мысль лучше.
2 и 3. Всё верно, и именно с этим явлением «закатывания частного общим» я веду борьбу. Благодарю за это разъяснение. Возможно оно позволит мне улучшить статью.
Интересно узнать Ваше мнение по основной части статьи, начиная с раздела «Человечная декомпозиция».
Мой основной посыл в том, что я вижу причину некачественного процесса декомпозиции, и как следствие низкого качества программных продуктов, в ложных убеждениях о человеческой природе. Первые 4 или часть из них могут заставлять ориентироваться на закон Паркинсона.
Я стремлюсь переломить эту распространенную ситуацию, предложив подход, исходящий из того, что люди могут быть и не такими. Стоит попробовать им доверять, и тогда, возможно, они раскроются, качество их работы улучшится, и они воспрянут духом. В результате и текучка может снизиться.
Ваши мысли созвучны моим. По пунктам:
1. Я не утверждаю, что ложные убеждения свойственны все в совокупности и всем людям на управляющих позициях. Интересно, что даже сами исполнители могут верить в эти убеждения, ухудшая этим жизнь на своём месте. Подумаю как сформулировать в статье свою мысль лучше.
2 и 3. Всё верно, и именно с этим явлением «закатывания частного общим» я веду борьбу. Благодарю за это разъяснение. Возможно оно позволит мне улучшить статью.
Интересно узнать Ваше мнение по основной части статьи, начиная с раздела «Человечная декомпозиция».
Этот комментарий должен был быть ответом на комментарий habr.com/ru/post/524678/#comment_22216000, но я промахнулся, а удалять комментарии нельзя.
Прошу вести дискуссию в рамках правильной ветки.
Благодарю JustDont, за такой развернутый и содержательный комментарий.
Мой основной посыл в том, что я вижу причину некачественного процесса декомпозиции, и как следствие низкого качества программных продуктов, в ложных убеждениях о человеческой природе. Первые 4 или часть из них могут заставлять ориентироваться на закон Паркинсона.
Я стремлюсь переломить эту распространенную ситуацию, предложив подход, исходящий из того, что люди могут быть и не такими. Стоит попробовать им доверять, и тогда, возможно, они раскроются, качество их работы улучшится, и они воспрянут духом. В результате и текучка может снизиться.
Ваши мысли созвучны моим. По пунктам:
1. Я не утверждаю, что ложные убеждения свойственны все в совокупности и всем людям на управляющих позициях. Интересно, что даже сами исполнители могут верить в эти убеждения, ухудшая этим жизнь на своём месте. Подумаю как сформулировать в статье свою мысль лучше.
2 и 3. Всё верно, и именно с этим явлением «закатывания частного общим» я веду борьбу. Благодарю за это разъяснение. Возможно оно позволит мне улучшить статью.
Интересно узнать Ваше мнение по основной части статьи, начиная с раздела «Человечная декомпозиция».
Прошу вести дискуссию в рамках правильной ветки.
Благодарю JustDont, за такой развернутый и содержательный комментарий.
Мой основной посыл в том, что я вижу причину некачественного процесса декомпозиции, и как следствие низкого качества программных продуктов, в ложных убеждениях о человеческой природе. Первые 4 или часть из них могут заставлять ориентироваться на закон Паркинсона.
Я стремлюсь переломить эту распространенную ситуацию, предложив подход, исходящий из того, что люди могут быть и не такими. Стоит попробовать им доверять, и тогда, возможно, они раскроются, качество их работы улучшится, и они воспрянут духом. В результате и текучка может снизиться.
Ваши мысли созвучны моим. По пунктам:
1. Я не утверждаю, что ложные убеждения свойственны все в совокупности и всем людям на управляющих позициях. Интересно, что даже сами исполнители могут верить в эти убеждения, ухудшая этим жизнь на своём месте. Подумаю как сформулировать в статье свою мысль лучше.
2 и 3. Всё верно, и именно с этим явлением «закатывания частного общим» я веду борьбу. Благодарю за это разъяснение. Возможно оно позволит мне улучшить статью.
Интересно узнать Ваше мнение по основной части статьи, начиная с раздела «Человечная декомпозиция».
Спасибо за статью, очень интересно и оригинальная идея. Хотел бы услышать от Вас ответы на вопросы ниже, учитывая, что модель уже применяете на практике.
Вот над этим я тоже размышлял, ваша цитата чтобы было понятно о чем я:
Тоже придерживался такой позиции пока был джуном. Но знаете что интересно? Я стал мидлом, и расту дальше, и вот какие мысли появляются. Если такие проекты отдаются джунам, то:
— Нет ли в данном конфликта интересов со стороны мидов и сеньоров? Ведь они могут почувствовать попытку уравнять их с джунами. Это, конечно, эгоизм, но во для многих здоровый эгоизм и является мотивацией развития в плане что: «вот я добился, значит чего-то стою» — такая некая спортивная составляющая их роста. Сюда же такие вещи как интерес для них изучить что-то более глубоко, что-то, что было отдано джунам.
— Нет ли проблемы, что некоторые джуны на драйве начинают после нескольких таких проектов «звездить»?
— Нет ли падения мотивации для мидлов и сеньоров? Как в плане «все равно джуны затащат», так и в плане «а почему не я, я ведь сеньор»?
— Какую работу продолжают выполнять миды и сеньоры на таких проектах? Только саппорт для джунов, или что-то еще?
Благодарю за ответы.
Вот над этим я тоже размышлял, ваша цитата чтобы было понятно о чем я:
Исходя из этой стратегии развития людей, стоит стараться чаще назначать хирургом не самого старшего, а самого младшего разработчика в команде и оказывать ему усиленную поддержку. Он будет вникать в фичу от уровня требований через декомпозицию с поддержкой наставника. Будучи максимально вовлечённым, младший разработчик будет ощущать драйв, осмысленность своей деятельности и быстрее расти.
Уже полтора года мы стараемся поступать таким образом, и опыт этот весьма результативный и благодатный.
Тоже придерживался такой позиции пока был джуном. Но знаете что интересно? Я стал мидлом, и расту дальше, и вот какие мысли появляются. Если такие проекты отдаются джунам, то:
— Нет ли в данном конфликта интересов со стороны мидов и сеньоров? Ведь они могут почувствовать попытку уравнять их с джунами. Это, конечно, эгоизм, но во для многих здоровый эгоизм и является мотивацией развития в плане что: «вот я добился, значит чего-то стою» — такая некая спортивная составляющая их роста. Сюда же такие вещи как интерес для них изучить что-то более глубоко, что-то, что было отдано джунам.
— Нет ли проблемы, что некоторые джуны на драйве начинают после нескольких таких проектов «звездить»?
— Нет ли падения мотивации для мидлов и сеньоров? Как в плане «все равно джуны затащат», так и в плане «а почему не я, я ведь сеньор»?
— Какую работу продолжают выполнять миды и сеньоры на таких проектах? Только саппорт для джунов, или что-то еще?
Благодарю за ответы.
Благодарю за теплые слова и очень уместный вопрос, HuckF1nn. Рад, что статья оказалась интересной и созвучной Вам.
Сложность в том, чтобы не впадать в крайности, а находить баланс.
Речь идёт о том, чтобы не все, но некоторые фичи, как правило не самые сложные, отдавать джуниорам, в качестве «хирургов».
Физически невозможно было бы отдавать все фичи джунам, ибо им нужно оказывать огромную поддержку.
Фичи бывают разными по уровню сложности, определённости и риска. Некоторые нужно обязательно отдавать сеньёрам.
Если найти баланс, то и конфликта интересов не будет. Старшие разработчики будут в достаточной степени удовлетворять и технические амбиции, и прокачивать софт скилы человеческого общения и менторства.
Важно, чтобы джунам не доставались только задачи из категории второстепенных механизмов, или задачи спущенные сверху с готовой жёсткой формулировкой «как делать?» и жёстким сроком, вместо «какую проблему нужно решить?».
Кстати, на мой взгляд, один из признаков достижения истинного уровня сеньёрности заключается в том, что уже не достаточно делать что-то очень круто своими руками, но возникает потребность делиться мастерством с другими.
Конфликт интересов скорее может возникать на уровне мидлов.
Вероятно, мне стоит поставить этот акцент на балансе в статье. Добавлю эту идею себе. Огромное спасибо!
Простых советов здесь быть не может. Радует, что ситуация на рынке труда создаёт для программистов условия, в которых работодатели вынуждены заботиться об истинном развитии сотрудников, пусть и ценой бОльших усилий и непростых решений. В противном случае мы наблюдаем текучку. То есть с трудом набранные люди занимаются бессмысленными на их уровне задачами, не приносят тот value, который могли бы, не растут, страдают и быстро уходят.
Не исключено, что я живу в «пузыре» и неадекватно оцениваю тенденции рынка. Но хочется верить, что всё близко к описанному.
Я ответил на вопросы? Или лучше сделать это по обозначенным пунктам?
Сложность в том, чтобы не впадать в крайности, а находить баланс.
Речь идёт о том, чтобы не все, но некоторые фичи, как правило не самые сложные, отдавать джуниорам, в качестве «хирургов».
Физически невозможно было бы отдавать все фичи джунам, ибо им нужно оказывать огромную поддержку.
Фичи бывают разными по уровню сложности, определённости и риска. Некоторые нужно обязательно отдавать сеньёрам.
Если найти баланс, то и конфликта интересов не будет. Старшие разработчики будут в достаточной степени удовлетворять и технические амбиции, и прокачивать софт скилы человеческого общения и менторства.
Важно, чтобы джунам не доставались только задачи из категории второстепенных механизмов, или задачи спущенные сверху с готовой жёсткой формулировкой «как делать?» и жёстким сроком, вместо «какую проблему нужно решить?».
Кстати, на мой взгляд, один из признаков достижения истинного уровня сеньёрности заключается в том, что уже не достаточно делать что-то очень круто своими руками, но возникает потребность делиться мастерством с другими.
Конфликт интересов скорее может возникать на уровне мидлов.
Вероятно, мне стоит поставить этот акцент на балансе в статье. Добавлю эту идею себе. Огромное спасибо!
Простых советов здесь быть не может. Радует, что ситуация на рынке труда создаёт для программистов условия, в которых работодатели вынуждены заботиться об истинном развитии сотрудников, пусть и ценой бОльших усилий и непростых решений. В противном случае мы наблюдаем текучку. То есть с трудом набранные люди занимаются бессмысленными на их уровне задачами, не приносят тот value, который могли бы, не растут, страдают и быстро уходят.
Не исключено, что я живу в «пузыре» и неадекватно оцениваю тенденции рынка. Но хочется верить, что всё близко к описанному.
Я ответил на вопросы? Или лучше сделать это по обозначенным пунктам?
Одни из своих посылок приходят к своим выводам. Вы соответственно поступили также, при этом указывая на ложность альтернативных утверждений. Лучше бы вы доказали их ложность, тогда было бы все понятно.
Но в статье Вы прямым текстом от этого доказательства уходите. Лично я не смог понять, чем ваш подход оказывается лучше к декомпозиции, не менее спорный на мой взгляд.
Благодарю за обратную связь iiopy4uk_mck! Она даёт пищу для размышлений и улучшения статьи.
Если я правильно понял Вашу мысль, то в статье не хватает обоснования ложности приведённых убеждений, ибо без них не понятно почему мой подход к декомпозиции лучше других подходов.
Год назад, будучи в самом начале пути познания философии, я думал, что могу пытаться обосновывать ложность этих убеждений на основе идей гуманизма, единственного, что я успел познать. github.com/alexpetrov/humanistic-work-decomposition
Но теперь я считаю, что я не достаточно компетентен, чтобы замахиваться на эту задачу. Вместо этого я предлагаю каждому человеку искать эти ответы самостоятельно, обращаясь к философским трудам, и, заглядывая внутрь себя, как критерий истины.
Кроме того, статься стала бы совершенно невменяемой по размеру и фокусировке.
Единственное, что мне следует уточнить в статье, что ложными эти убеждения становятся, когда претендуют на всеобщность, в то время как они являются просто распространёнными, но частными случаями. Порождаются они неблагоприятными обстоятельствами жизни большинства людей.
Спорность моего подхода неизбежна, ибо он требует повышенных душевных усилий и слабо поддаётся наукообразному обоснованию. Но мне он помог радикально улучшить рабочую ситуацию, только поэтому я им делюсь, в надежде, что он поможет кому-то ещё.
Если я правильно понял Вашу мысль, то в статье не хватает обоснования ложности приведённых убеждений, ибо без них не понятно почему мой подход к декомпозиции лучше других подходов.
Год назад, будучи в самом начале пути познания философии, я думал, что могу пытаться обосновывать ложность этих убеждений на основе идей гуманизма, единственного, что я успел познать. github.com/alexpetrov/humanistic-work-decomposition
Но теперь я считаю, что я не достаточно компетентен, чтобы замахиваться на эту задачу. Вместо этого я предлагаю каждому человеку искать эти ответы самостоятельно, обращаясь к философским трудам, и, заглядывая внутрь себя, как критерий истины.
Кроме того, статься стала бы совершенно невменяемой по размеру и фокусировке.
Единственное, что мне следует уточнить в статье, что ложными эти убеждения становятся, когда претендуют на всеобщность, в то время как они являются просто распространёнными, но частными случаями. Порождаются они неблагоприятными обстоятельствами жизни большинства людей.
Спорность моего подхода неизбежна, ибо он требует повышенных душевных усилий и слабо поддаётся наукообразному обоснованию. Но мне он помог радикально улучшить рабочую ситуацию, только поэтому я им делюсь, в надежде, что он поможет кому-то ещё.
Вот согласен, что подходы хороши в контексте. И те старые догматы даются в контексте, который хорошо описывают авторы в своих книгах. Поэтому мне/читателю их трудов становится намного легче понять на сколько коррелирует их книжная ситуация с моей.
Вы могли конечно их не опровергать, тогда нужено более структурированное и полное (на несколько статей) описание контекста в котором ваш подход работает.
И еще одно маленькое замечание. В статье вы говорите о ложности постулатов, с чем я не согласен. Но полностью согласен с вашим комментарием о том, что они ни какие не всеобщие. Имхо, эта точность пошла бы статье на пользу, тем более Вы это и сами понимаете.
Благодарю за эти мысли, iiopy4uk_mck!
Мне нужно переварить их, и я обязательно отвечу чем-то содержательным.
Мне нужно переварить их, и я обязательно отвечу чем-то содержательным.
Ещё раз благодарю за вклад в улучшение статьи. Упомянул Вас в changelog.
Моя странная особенность в том, что я никогда не встречал книг, которые бы отталкивались от обозначенных убеждений о человеческой природе как истинных. Видимо это эффект склонности к подтверждению своей точки зрения (confirmation bias). Хотя статей, опирающихся на полезность отталкивания от закона Паркинсона, встречал много в ИТ сфере. И очень мало статей с ним не соглашающихся.
Мне было бы полезно узнать о таких книгах, которые Вам попадались и опирались на истинность данных убеждений.
Хотя, возможно, я Вас не так понял, и Вы находите непоследовательным лишь ход моих рассуждений, который не достаточно обосновывает мои советы.
Описание контекста я тоже вынашиваю. Спасибо Вам за вдохновение!
Моя странная особенность в том, что я никогда не встречал книг, которые бы отталкивались от обозначенных убеждений о человеческой природе как истинных. Видимо это эффект склонности к подтверждению своей точки зрения (confirmation bias). Хотя статей, опирающихся на полезность отталкивания от закона Паркинсона, встречал много в ИТ сфере. И очень мало статей с ним не соглашающихся.
Мне было бы полезно узнать о таких книгах, которые Вам попадались и опирались на истинность данных убеждений.
Хотя, возможно, я Вас не так понял, и Вы находите непоследовательным лишь ход моих рассуждений, который не достаточно обосновывает мои советы.
Описание контекста я тоже вынашиваю. Спасибо Вам за вдохновение!
Добавил описание контекста и запись об этом в Changelog.
Буду признателен за обратную связь по этим двум изменениям вдохновлённым Вами.
Буду признателен за обратную связь по этим двум изменениям вдохновлённым Вами.
Предварительная оценка трудозатрат является согласованным значением между какими-то участниками процесса? Или, например, работник назначает её сам себе?
Благодарю за хороший вопрос, jimni! Действительно, важно для себя ли делаются оценки.
Я добавляю слово «предварительная», чтобы сделать акцент на её неокончательности и условности. Эта оценка нужна не для менеджмента, чтобы наказать исполнителя или оценщика в случае непопадания. Она нужна для самого человека, занимающегося декомпозицией, чтобы грубо оценивать задачи и от чего-то отталкиваться. Возможно, лучше было бы использовать более абстрактные оценки в условных попугаях. Эти оценки больше нужны для соотнесения задач в декомпозиции относительно друг друга, чтобы можно было отвечать на контрольные вопросы об их качествах.
У нас в компании оценки делаются в днях для того чтобы не усложнять процесс вводом дополнительных абстрактных единиц. При этом всем участникам дают понять, что не уложиться в оценку это абсолютно нормально. Желательно проанализировать причину непопадания и попытаться скорректировать свой «глазомер» на будущее, если это вообще возможно в условиях огромного разнообразия задач и обстоятельств.
После перехода на человечную декомпозицию, получается так, что основной исполнитель по фиче занимается декомпозицией. Ключевые задачи по смысловому ядру он берёт себе и оценки он делает для себя. Вспомогательные задачи он делает на помощников в этой фиче, желательно, спрашивая у них оценку или предлагая согласовать свою. При этом оценки не влияют ни на какие KPI.
Весь процесс декомпозиции ведётся в трекере и наблюдать за ним могут все участники команды, находя и предлагая возможности для улучшения. Если декомпозицию проводит сотрудник с небольшим опытом в этих делах, то ему более активно помогают выделенные для этого коллеги. Сначала сотрудник описывает в виде комментария совокупность задач, не создавая настоящих задач. Так удобнее вносить изменения и видеть общую картину.
Я добавляю слово «предварительная», чтобы сделать акцент на её неокончательности и условности. Эта оценка нужна не для менеджмента, чтобы наказать исполнителя или оценщика в случае непопадания. Она нужна для самого человека, занимающегося декомпозицией, чтобы грубо оценивать задачи и от чего-то отталкиваться. Возможно, лучше было бы использовать более абстрактные оценки в условных попугаях. Эти оценки больше нужны для соотнесения задач в декомпозиции относительно друг друга, чтобы можно было отвечать на контрольные вопросы об их качествах.
У нас в компании оценки делаются в днях для того чтобы не усложнять процесс вводом дополнительных абстрактных единиц. При этом всем участникам дают понять, что не уложиться в оценку это абсолютно нормально. Желательно проанализировать причину непопадания и попытаться скорректировать свой «глазомер» на будущее, если это вообще возможно в условиях огромного разнообразия задач и обстоятельств.
После перехода на человечную декомпозицию, получается так, что основной исполнитель по фиче занимается декомпозицией. Ключевые задачи по смысловому ядру он берёт себе и оценки он делает для себя. Вспомогательные задачи он делает на помощников в этой фиче, желательно, спрашивая у них оценку или предлагая согласовать свою. При этом оценки не влияют ни на какие KPI.
Весь процесс декомпозиции ведётся в трекере и наблюдать за ним могут все участники команды, находя и предлагая возможности для улучшения. Если декомпозицию проводит сотрудник с небольшим опытом в этих делах, то ему более активно помогают выделенные для этого коллеги. Сначала сотрудник описывает в виде комментария совокупность задач, не создавая настоящих задач. Так удобнее вносить изменения и видеть общую картину.
Александр, привет! Большое спасибо за статью — прочитал с большим удовольствием. Мне особенно нравится, что ты ссылаешься на философию и выстраиваешь цепочки не от бизнеса, а от «духовности». Такой подход мне близок.
Как большой фанат и практик микро-таскинга, хочу сделать несколько комментариев. Во-первых, его действительно можно использовать во зло. Если дать нерадивому «менеджеру» (собирательный образ) любой инструмент — он умудрится его испортить. Например тотальным контролем, недоверием, алчностью или глупостью.
В моем случае, микротаскинг — пример того, как можно структурировано общаться, думать об архитектуре, сроках поставки, соблюдении качества и блокировках.
И самый главный мой аргумент:
> Участвуя в производстве такого характера, человек теряет связь с результатами своего труда, отчуждается от них. Для человека исчезает смысл в его деятельности, он ощущает подавленность и тревогу. Всё это ведёт к раннему профессиональному выгоранию и более тяжёлым последствиям.
Напротив, я вижу и слышу, что люди становятся «счастливы» от такой формы организации работы. Потому что результат видно сразу. Ты сделал что-то – и вот оно! Уже в проде, работает! Еще очень многих мотивирует прозрачность и «понятность» процесса.
Я основываю свои практики на том, как ведется разработка в open-source. Где люди *добровольно* организовывают работу похожим образом (с некоторыми допущенями, что open-source пилится урывками раз в неделю перед сном). Вот тут есть хорошее демо: github.com/wemake-services/wemake-python-styleguide Сотни людей, тысячи задачек. Работает как часы. А главное, приносит людям кучу удовольствия. От процесса и результата.
К сожалению, данный процесс почти не освещен в публичном поле. Да и скажу честно, запроса на освещение тоже нет.
И последнее:
> Команды должны состоять из небольшого числа самомотивированных и высокопродуктивных профессионалов.
Имея такую вводную, можно использовать почти любую организацию процесса. Хоть листочки на доске, хоть микро-таски, хоть #NoEstimates. Людям главное не мешать. Проблема возникает, когда такой вводной нет. А её нет в большом количестве случаев. Что делать в таких случаях – я не знаю.
В итоге, можно сказать, что к счастью ведут разные дороги. Главное, понимать, по какой нужно идти именно тебе.
Как большой фанат и практик микро-таскинга, хочу сделать несколько комментариев. Во-первых, его действительно можно использовать во зло. Если дать нерадивому «менеджеру» (собирательный образ) любой инструмент — он умудрится его испортить. Например тотальным контролем, недоверием, алчностью или глупостью.
В моем случае, микротаскинг — пример того, как можно структурировано общаться, думать об архитектуре, сроках поставки, соблюдении качества и блокировках.
И самый главный мой аргумент:
> Участвуя в производстве такого характера, человек теряет связь с результатами своего труда, отчуждается от них. Для человека исчезает смысл в его деятельности, он ощущает подавленность и тревогу. Всё это ведёт к раннему профессиональному выгоранию и более тяжёлым последствиям.
Напротив, я вижу и слышу, что люди становятся «счастливы» от такой формы организации работы. Потому что результат видно сразу. Ты сделал что-то – и вот оно! Уже в проде, работает! Еще очень многих мотивирует прозрачность и «понятность» процесса.
Я основываю свои практики на том, как ведется разработка в open-source. Где люди *добровольно* организовывают работу похожим образом (с некоторыми допущенями, что open-source пилится урывками раз в неделю перед сном). Вот тут есть хорошее демо: github.com/wemake-services/wemake-python-styleguide Сотни людей, тысячи задачек. Работает как часы. А главное, приносит людям кучу удовольствия. От процесса и результата.
К сожалению, данный процесс почти не освещен в публичном поле. Да и скажу честно, запроса на освещение тоже нет.
И последнее:
> Команды должны состоять из небольшого числа самомотивированных и высокопродуктивных профессионалов.
Имея такую вводную, можно использовать почти любую организацию процесса. Хоть листочки на доске, хоть микро-таски, хоть #NoEstimates. Людям главное не мешать. Проблема возникает, когда такой вводной нет. А её нет в большом количестве случаев. Что делать в таких случаях – я не знаю.
В итоге, можно сказать, что к счастью ведут разные дороги. Главное, понимать, по какой нужно идти именно тебе.
Привет, Никита! Рад тебя слышать! Огромное спасибо за добрые слова и ценные вопросы!
Я их покручу в голове и завтра отвечу.
Я их покручу в голове и завтра отвечу.
Спасибо за этот вклад, Никита!
По части микротаскинга. В статье я говорю о ситуации доведения размера задачи до абсолютного минимума, которая пропагандируется Zerocracy. Мне показалось уместным при обсуждении моего подхода показать от чего в пределе я хочу предостеречь людей. Однажды во время уборки дома мне пришла эта идея с континуумом стилей декомпозиции от экстремально мелких задач, до отсутствия очерчивания границ задач совсем. Меня всегда волновал вопрос внутреннего неприятия подхода Zerocracy и я решил свои мысли органично вплести в своё эссе.
Очевидно ты говоришь совсем не о таком отчуждающем микротаскинге, раз результат задачи попадает на прод и приносит удовлетворённость исполнителю. Твой подход в этом континууме находится ближе к моему. Я бы его назвал минитаскингом. Полагаю, люди в подразумеваемом тобой подходе не говорят: «Я не ассоциирую себя с результатом моего труда, я его полностью отчуждаю»? У них сохраняется профессиональная гордость за результат труда как это было с ремесленниками до возникновения капитализма.
Опишу типичный контекст, в котором мой подход возник. Я говорю о разработке некоей новой большой бизнес-фичи дней на 10—12 разработки в предварительной оценке, допустим, с несколькими экранами, хранимыми моделями, алгоритмом вычисления чего-нибудь и рассылкой результатов вычисления куда-то.
И я утверждаю, что мне комфортно разрбатывать её целиком, отдавая разве что какие-то второстепенные механизмы помощникам, чтобы разгрузить голову. Создавая для себя подзадачи с целостными границами, которые помогают мне строить мыслительный процесс. Я испытываю паралич, если эти границы провёл за меня кто-то другой и выставил срок. Даже при том, что официально нас за непопадание в срок никто не наказывает, мой внутренний критик требует, чтобы я в сроки попадал, и это меня тоже парализует.
Пример с OpenSource понятен и хорош, но и в OpenSource не все проекты могут разрабатываться большим числом людей небольшими приращениями. Бывает проекты требующие целостного подхода какого-то единого мыслителя носителя видения. Я имею в виду точку зрения Рича Хикки. Всё зависит от характера проекта. Сложно делать обобщения.
>> Команды должны состоять из небольшого числа самомотивированных и высокопродуктивных профессионалов.
> Имея такую вводную, можно использовать почти любую организацию процесса. Хоть листочки на доске, хоть микро-таски, хоть #NoEstimates. Людям главное не мешать.
Это справедливо. Я лишь подчеркнул, что для #NoEstimates это условие является необходимым, а для других более распространенных ситуаций можно справляться, имея смешанную команду разработчиков разного уровня. Но чтобы при этом получать качественный результат нужно делегировать им декомпозицию и обучать их этому.
> В итоге, можно сказать, что к счастью ведут разные дороги. Главное, понимать, по какой нужно идти именно тебе.
Совершено согласен. Надеюсь моя дорога, будучи извлеченной из моей интуиции и описанной, станет ещё одной альтернативой для людей.
Было бы интересно узнать больше о твоей системе микротаскинга, например, в сравнении с Zerocracy, так как меня эта тема по настоящему трогает.
По части микротаскинга. В статье я говорю о ситуации доведения размера задачи до абсолютного минимума, которая пропагандируется Zerocracy. Мне показалось уместным при обсуждении моего подхода показать от чего в пределе я хочу предостеречь людей. Однажды во время уборки дома мне пришла эта идея с континуумом стилей декомпозиции от экстремально мелких задач, до отсутствия очерчивания границ задач совсем. Меня всегда волновал вопрос внутреннего неприятия подхода Zerocracy и я решил свои мысли органично вплести в своё эссе.
Очевидно ты говоришь совсем не о таком отчуждающем микротаскинге, раз результат задачи попадает на прод и приносит удовлетворённость исполнителю. Твой подход в этом континууме находится ближе к моему. Я бы его назвал минитаскингом. Полагаю, люди в подразумеваемом тобой подходе не говорят: «Я не ассоциирую себя с результатом моего труда, я его полностью отчуждаю»? У них сохраняется профессиональная гордость за результат труда как это было с ремесленниками до возникновения капитализма.
Опишу типичный контекст, в котором мой подход возник. Я говорю о разработке некоей новой большой бизнес-фичи дней на 10—12 разработки в предварительной оценке, допустим, с несколькими экранами, хранимыми моделями, алгоритмом вычисления чего-нибудь и рассылкой результатов вычисления куда-то.
И я утверждаю, что мне комфортно разрбатывать её целиком, отдавая разве что какие-то второстепенные механизмы помощникам, чтобы разгрузить голову. Создавая для себя подзадачи с целостными границами, которые помогают мне строить мыслительный процесс. Я испытываю паралич, если эти границы провёл за меня кто-то другой и выставил срок. Даже при том, что официально нас за непопадание в срок никто не наказывает, мой внутренний критик требует, чтобы я в сроки попадал, и это меня тоже парализует.
Пример с OpenSource понятен и хорош, но и в OpenSource не все проекты могут разрабатываться большим числом людей небольшими приращениями. Бывает проекты требующие целостного подхода какого-то единого мыслителя носителя видения. Я имею в виду точку зрения Рича Хикки. Всё зависит от характера проекта. Сложно делать обобщения.
>> Команды должны состоять из небольшого числа самомотивированных и высокопродуктивных профессионалов.
> Имея такую вводную, можно использовать почти любую организацию процесса. Хоть листочки на доске, хоть микро-таски, хоть #NoEstimates. Людям главное не мешать.
Это справедливо. Я лишь подчеркнул, что для #NoEstimates это условие является необходимым, а для других более распространенных ситуаций можно справляться, имея смешанную команду разработчиков разного уровня. Но чтобы при этом получать качественный результат нужно делегировать им декомпозицию и обучать их этому.
> В итоге, можно сказать, что к счастью ведут разные дороги. Главное, понимать, по какой нужно идти именно тебе.
Совершено согласен. Надеюсь моя дорога, будучи извлеченной из моей интуиции и описанной, станет ещё одной альтернативой для людей.
Было бы интересно узнать больше о твоей системе микротаскинга, например, в сравнении с Zerocracy, так как меня эта тема по настоящему трогает.
> У них сохраняется профессиональная гордость за результат труда как это было с ремесленниками до возникновения капитализма.
Да! Ровно та идея, которая является для меня ключевой. Когда я начинал, я решил отталкиваться от своих ценностей при построении бизнеса. На вопрос «что же я люблю в своей работе?» — главным ответом было «я люблю писать качественный код». Без данной установки — все остальное вообще не имеет смысла. Следовательно, нам было важно создать такую систему, где данная установка работала бы. От нее отталкиваются все остальные идеи: FFF (мы практикуем активно, без него микро-таски не выходят), полная автоматизация всего (оттуда растет весь наш open-source), DDD и программныые средства выразительности для него (без него вообще ничего не работает).
Тут возникает важный вопрос «но бизнесу же неважно качества кода, ему важно Х!»
На что могу сказать, что нам в свою очередь не интересен такой бизнес. Потому что есть большое число компаний, которые хотят получить именно то, что мы предлагаем.
> Было бы интересно узнать больше о твоей системе микротаскинга, например, в сравнении с Zerocracy, так как меня эта тема по настоящему трогает.
Не могу сравнивать, потому что почти ничего про них не знаю. Плюс, меня немного отталкивает их способ маркетинга и заявленные цели. Для меня звучит абсурдно, что люди идут работать программистами из-за денег. Тогда, было бы логично пойти в рекламу ставок, например, там значительно больше денег.
Но про свою компанию я рассказываю, как могу: sobolevn.me/talks/teamleadconf-2020
Полная коллекция тут: sobolevn.me
Для независимого наблюдателя есть возможность сравнить.
Да! Ровно та идея, которая является для меня ключевой. Когда я начинал, я решил отталкиваться от своих ценностей при построении бизнеса. На вопрос «что же я люблю в своей работе?» — главным ответом было «я люблю писать качественный код». Без данной установки — все остальное вообще не имеет смысла. Следовательно, нам было важно создать такую систему, где данная установка работала бы. От нее отталкиваются все остальные идеи: FFF (мы практикуем активно, без него микро-таски не выходят), полная автоматизация всего (оттуда растет весь наш open-source), DDD и программныые средства выразительности для него (без него вообще ничего не работает).
Тут возникает важный вопрос «но бизнесу же неважно качества кода, ему важно Х!»
На что могу сказать, что нам в свою очередь не интересен такой бизнес. Потому что есть большое число компаний, которые хотят получить именно то, что мы предлагаем.
> Было бы интересно узнать больше о твоей системе микротаскинга, например, в сравнении с Zerocracy, так как меня эта тема по настоящему трогает.
Не могу сравнивать, потому что почти ничего про них не знаю. Плюс, меня немного отталкивает их способ маркетинга и заявленные цели. Для меня звучит абсурдно, что люди идут работать программистами из-за денег. Тогда, было бы логично пойти в рекламу ставок, например, там значительно больше денег.
Но про свою компанию я рассказываю, как могу: sobolevn.me/talks/teamleadconf-2020
Полная коллекция тут: sobolevn.me
Для независимого наблюдателя есть возможность сравнить.
Огромное спасибо, Никита, за пояснение и шикарный доклад!
Я понял в чем отличие твоего подхода от Zerocracy, и почему он гораздо ближе к моей концепции человечности изложенной в статье.
Я обязательно добавлю раздел с разъяснением этого различия, чтобы не возникало негативного отношения к микротаскам в более широком смысле, чем это обозначено в экстремальном подходе Zerocracy.
Я понял в чем отличие твоего подхода от Zerocracy, и почему он гораздо ближе к моей концепции человечности изложенной в статье.
Я обязательно добавлю раздел с разъяснением этого различия, чтобы не возникало негативного отношения к микротаскам в более широком смысле, чем это обозначено в экстремальном подходе Zerocracy.
Данный тред подсветил важный аспект. Даже если мы находимся в ситуации, когда требуется более высокая прозрачность процесса разработки за счет более мелкого дробления на задачи, важно чтобы это дробление делал сам исполнитель. Я предполагаю, что в подходе Никиты большинство задач будет больше 15 минут, и даже больше 1 часа, в отличие от подхода микротаскинга, который я привёл как экстремальный, когда большинство задач не будет превышать получаса и постановка будет делаться другим обезличенным разработчиком. Важно, что оплата в подходе Никиты делается не за каждую задачу, а за осмысленный целостный результат.
Повышенная прозрачность процесса в случае Никиты требуется из-за того, что есть заказчики или менеджмент, которые не слишком погружены в специфику и проблемы разработки. Проекты делаются для внешних заказчиков, которые жёстко спрашивают о затратах.
Благо в команде все разработчики уровня senior с высокой продуктивностью и сознательностью. Даже за 15 минут они могут разработать что-то существенное, готовое к выпуску в продакшн.
У нас в FunBox немного другая ситуация для разработчиков. Мы разрабатываем долгоживущие в нашей инфраструктуре продукты для заказчика, полностью на нашей поддержке. Этих продуктов много и разработчики в командах долго бывают привязаны к одному проекту. Разработчики чувствуют долгосрочную заинтересованность в качестве ибо им этот код и сопровождать. Так как проектов много, мы не можем работать только с senior-ами. Типичная команда состоит из профессионалов с разным опытом, и младшим разработчикам оказывается поддержка. Менеджмент, силами технического руководства, хорошо осведомлён о сложности разработки и доверяет командам. Всё это приводит к тому, что прозрачность снаружи не требуется, и деление на задачи можно осуществлять только в интересах разработчика. Это позволяет для новых фич не создавать задач размером меньше двух часов. Понимается, что если фича новая, то всегда вылезет что-то над чем нужно подумать. Нужно посмотреть как подобные вещи сделаны в кодовой базе для единого стиля, исследовать требования.
На мой взгляд подход Никиты соответствует идеям человечной декомпозиции, в контексте фирмы разработчика заказных продуктов, командой из 10 высококлассных профессионалов.
Я рекомендую доклад Никиты [[https://sobolevn.me/talks/teamleadconf-2020][Practical Microtasks]] в качестве дополнения. Всё практики, о которых Никита рассказывает мы применяем в FunBox, с тем отличием, что большинство проектов у нас на Elixir, Erlang и Ruby, а не Python. Хотя Python тоже используем в DataScience области.
Обсудив в ЛС, мы с Никитой решили, что в статью излишне добавлять это разъяснение. Достаточно сделать его в виде данного комментария.
поправлю ссылку: sobolevn.me/talks/teamleadconf-2020
Sign up to leave a comment.
Человечная декомпозиция работы