Посадите программиста в поток. Защищайте. Не мешайте. Наслаждайтесь

    Нужна справка на каждого ребенка. Да, и согласие на обработку персональных данных. От каждого из родителей. Пусть и анкету каждый заполнит. Статистический отчет о том, сколько мальчиков и девочек. Да, и по возрастам. И по районам прописки. Ну и по школам. Разделите там, пожалуйста, обычные школы, лицеи и гимназии. Нет, педсовет пропускать нельзя. Это всего 4 часа. Раз в неделю. Да, всем педагогам надо прийти. Конечно, вам нужно работать еще и в детских садах. Каждому из вас. Трижды в неделю. И костюмы ваши нам не нравятся, нужно меньше красок – чего как попугаи-то?

    Так, а почему новых постановок нет? Где победы на конкурсах? Что значит два месяца бегаете бумажки собираете? Какое еще творчество? И почему у вас на него времени нет? Какого еще секретаря вам нанять? Что значит «я ухожу»? Вы серьёзно думаете, что справитесь без нас? Что ж, удачи.

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

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

    Что будет если?


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

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

    Ну и главное: в срок программист всё равно не попадает, хоть убей. А если попадает, то лишь иногда, случайно. Либо ценой снижения продуктивности.

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

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

    Как планировать выполнение такой работы? Принципиально подхода четыре – фантазии, резерв, объем и поток.

    Методы «планирования»


    Фантазии – это применение к работе программистов методов планирования серийного производства. Например, Lean или MRP. Этим подходом пользуются все «классические менеджеры», особенно отдельная их каста – «управленцы». Надо просто выдавить из программиста плановые трудозатраты, игнорируя все его вопли типа «блин, да я даже близко не знаю, с чем там столкнусь», и нарисовать красивую колбаску на диаграмме Ганта. И перерисовывать каждый день.

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

    Объем – это когда планируются не сроки решения задач, а продуктивность. Например, такой подход используется в Scrum – зная примерную скорость работы команды (в story points), можно запланировать объем работы за спринт (в тех же SP). Соответственно, у всех задач спринта один и тот же срок исполнения.

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

    Плюсы и минусы


    Фантазийный подход даже обсуждать смысла нет – он не работает. Мало того – он еще и создаёт постоянный, дикий стресс и идиотскую работу по перепланированию. Жить можно, если перепланированием занимается не программист, а кто-то другой, но так бывает редко. Обычно программиста просто долбят каждый день вопросами типа «назови мне срок», «когда ты уже доделаешь эту задачу?» или «уже все сроки прошли, ты будешь работать или нет?». Естественным, гармоничным путём программист приходит к резервам времени, даже если ничего не знает ни о каких модных методиках.

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

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

    Объёмные методы, типа Scrum, повышают продуктивность примерно вдвое, т.к. снижают влияние закона Паркинсона и ориентируются на более или менее реальную продуктивность, а не фантазии и резервы времени. Однако спринт – это всё равно срок, поэтому закон Паркинсона продолжает действовать, как и резервирование времени и попытки манипуляции оценками (story points). Люди есть люди – и программисты, и менеджеры. Программисты хотят быть хорошими сотрудниками. А менеджеры настолько привыкли считать хорошими сотрудниками только тех, кто «успевает в срок», что хоть кол на голове теши. Просто называться всё это будет по-другому – типа «все таски бэклога должны быть выполнены в пределах спринта, и нечего тут фасилитировать». И ещё какой-нибудь KPI под это дело придумают, ибо фантазия небогата.

    В потоке этих проблем нет, т.к. отсутствует их причина – планирование работы программиста и попытки, так или иначе, оценить сроки исполнения работ. Поток защищает суть работы программиста – творчество. Хочется, конечно, сказать, что поток – это чистое творчество, но так не бывает. Однако, чистота намного выше. И продуктивность возрастает еще вдвое, по сравнению с Scrum.

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

    Что в основе любого метода


    Например, Lean, как ни странно, так же основан на идее потока, т.к. придуман на конвейере. Идея в том, чтобы выстроить работу максимально равномерно и гармонично. Чтобы у каждого исполнителя в цепочке, с одной стороны, всегда было чем заняться, а с другой – чтобы перед ним не было очереди. Только минимально необходимый запас работы. Для программиста это – одна задача. Попробуйте менеджеру, знатоку Lean, подать эту идею – он даже не поймёт, о чём речь, т.к. пропустил раздел о защите исполнителей, когда читал статью в википедии про бережливое производство.

    В Теории ограничений, которая про резервы, защита звена-исполнителя – вообще базовый постулат. Там, где сидят программисты, они почти всегда – бутылочное горлышко. Что в ТОС написано про бутылочное горлышко? Правильно – его надо защищать. Убрать всю непрофильную загрузку (включая планирование собственной работы), не допускать простоев, не конопатить мозги дурацкими вопросами и совещаниями. Организовать поток работы той скорости, с которой работает бутылочное горлышко. Ну-ка, менеджеры-знатоки ТОС, признайтесь – давно вы думали о том, как защитить программистов от всякой дури?

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

    Итого


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

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

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

    Средняя зарплата в IT

    111 000 ₽/мес.
    Средняя зарплата по всем IT-специализациям на основании 7 000 анкет, за 2-ое пол. 2020 года Узнать свою зарплату
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

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

      +47

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

        +8
        Если программисты перестают париться насчет сроков, и просто решают задачи, одну за другой, ни на что не отвлекаясь, то продуктивность возрастает вдвое.


        это голословный комментарий или автор готов прийти в коллектив разработчиков и за деньги сделать x2 продуктивности?
          +14
          я этим и занимаюсь
            +4
            Только х2?
            Сосредоточенность + комфорт + спокойная атмосфера это 2^3.

            Потоковое состояние очень недооцененная вещь в профессиях, одновременно
            творческих и мастерских
              0
              Да согласен на все 100
                –1
                По моим ощущениям у потока есть обратная сторона. Можно на этой скорости выдать не очень качественные решения, легче забить на какие-то не самые правильные моменты. Некоторые задачи требуют неспешности и аккуратности, которые в потоке не в приоритете.
                  +1
                  Ещë обратная сторона обратная сторона нахождения в потоке, как мне кажется, — это отсутствие связи с командой, с продуктом, с контекстом. Но само состояние потока — это да, дорогого стоит))))
                    0
                    У нас с вами какой-то разный поток.
                      0
                      Некоторые задачи требуют неспешности и аккуратности

                      Вот именно — а когда программиста постоянно дёргают…
                    +4
                    Есть простой факт, как только вы запросили у человека оценку. Вы просадили его производительность вдвое.

                    Тут картинка Дорофеева про горшки и говно.
                      0
                      image
                      +14

                      Раньше он даже x4 делал, но, судя по теперешним статьям, не очень-то спросом пользовалось. Перешёл на x2.

                        –1
                        Хотел написать коммент, что совещаться всё-же полезно, главное чтобы это не было похоже на постоянное отдёргивание от работы (программирования). Но Ваш коммент (или цитата в нём) каким-то образом навели на новую мысль — что всё-же программисту лучше действительно решать поставленные кем-то задачи. А думают и ставят эти задачи пусть другие, специальные люди, — пусть они спорят, ходят на совещания, вырабатывают стратегию и архитектуру, решают оргвопросы… А программисты пусть просто это воплощают. Так будет эффективнее, IMHO.
                          +1

                          Попробовал так как-то. Программисты сделали не то и слишком поздно. Лучше контекст им все-таки давать)

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

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

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

                                    Или просто договориться работать без ТЗ.

                                0
                                Согласна, чтобы нормально что-то сделать нужно понимать, что ты делаешь и, что в конечном итоге должно получиться. Так даже рутина не кажется такой тоскливой.
                                +1
                                Как быстро такой разработчик выгорит и уволится? Мало кто хочет просто исполнять инструкции.
                                  0
                                  То есть программист, который не любит программировать (кодировать), а хочет быть архитектором? Ну и правильно уволится — пусть идёт заниматься любимым делом, — становится архитектором, проектирует, а не кодирует.
                                    0

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


                                    А в некоторых методологиях, например Скрам, архитекторов вообще не предусмотрено.

                                      0
                                      в некоторых методологиях архитекторов вообще не предусмотрено

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

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

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

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

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

                                пойду закажу эту фразу в золотом тиснении, чтобы в офисе повесить
                                  +2
                                  Но, кстати, тут есть нюанс. Вот тот самый «руководитель танцевального коллектива», который был во вступлении — он как раз менеджер. Есть у меня сомнения, что он лично танцевал. Поэтому описанные задачи, от которых он ушел — они как раз его и есть.
                                    +1
                                    Худрук и управленец обычно разные люди. Но в маленьких коллективах это один человек. Я тоже видел случаи, когда хореографа загружали менеджерской работой, которую тот делать не умел и не хотел.
                                      +1
                                      А тогда тут очевидная проблема, что хореограф стал руководителем. А он не руководитель, он хореограф.
                                      Ну это приблизительно как когда синьор становится начальником отдела разработки и думает, что он будет продолжать программировать, только название должности круче и денег дают больше.
                                        +3
                                        Вот этого вообще стоит дико бояться, если не чувствуются менеджерские наклонности.
                                        Можно просто забыть что такое программирование и решение инженерных задач. Сплошные совещания, совещания и совещания, а потом тебя долбят почему ты проект не закрыл (про совещания к этому моменту все забыли).
                                      0
                                      Не, ровно наоборот. Он не только танцевал, но и продолжает это делать — в другом, «взрослом» коллективе. То есть он прям худрук.
                                        0
                                        Поэтому описанные задачи, от которых он ушел
                                        Взгляните ещё раз на все упомянутые задачи. Подумайте. И поставьте перед определением «руководитель» прилагательное «художественный». Чувствуете, как изменился акцент?
                                        и да, я долго пишу комментарии…
                                        +2

                                        А как же плач тысяч о том, что мереджеры сроки спускают, не согласовывая с исполнителями?

                                          0
                                          Вот именно, не очень понятно как это конкретно должно работать в айти
                                            +2
                                            Хороший менеджер должен правильно оценивать сроки. Неправильно оценил, команда не успела — команда не виновата, виноват менеджер. Он не должен спускать сроки — он должен их поднимать, т.е. отдавать наверх свою оценку. Команде при этом, про названные им сроки, знать вообще необязательно.
                                          +2
                                          Над одним продуктом работает 20 фуллстековых команд. Релизный цикл, соответственно, общий для всех. Работа по LeSS.
                                          Кто должен оценку давать? Техдир, как самый общий для всех управленец? Скрам-мастер? Руководители/лиды платформ? Завести 20 управленцев уровня команды?
                                          Так что на каком-то масштабе руководитель ещё что-то способен оценить, но на большем, всё, что он может сделать — не мешать оценивать командам.
                                            +1
                                            Так что на каком-то масштабе руководитель ещё что-то способен оценить, но на большем, всё, что он может сделать — не мешать оценивать командам.

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

                                            Кто должен оценку давать? Скрам-мастер?

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

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

                                                тогда и менеджеры не понадобятся

                                                Достаточно эффективные программисты-менеджеры предпочитают работать соло, а не в команде. Иначе придётся менеджерские задачи решать не только за себя, но и за коллег, а это уже неэффективно для второй сущности человека-оркестра: программистской.
                                              +1
                                              Вопрос в необходимости глубины дискретизации оценки. Если нужна оценка по продукту в целом — то да, техдир.
                                              Оценивать в основном статистически. На больших масштабах оценка не зависит от состава задач, а только их количества. Но команды начнут работать гораздо бодрее, если фаза оценки пропадет.
                                            +12
                                            Доброго времени суток! Идея описана интересная, но совершенно не понятно, как её применять в жизни. Не могли бы Вы ответить на несколько вопросов?
                                            1. Вы пишите:
                                            Поток – это когда есть только скорость. Задачи выстраиваются в очередь, программист садится и решает одну за другой. Сроки не известны, но их можно вычислить – зная скорость и номер задачи в очереди. Главное – не озадачивать вычислением срока самого программиста.

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

                                            2. Представьте, что Вы придумали проект/идею и нанимаете фрилансера. Час его работы стоит 100$. Вы описываете задачу, и, наверное, хотите узнать, сколько он будет её делать. Но у него поток, он отвечает, что он, вообще-то, творец и сроки будут такие, какие будут. И в процессе работы не отвлекайте его, на «митинги». Он сам напишет, когда закончит. При этом у Вас есть бюджет и сроки, и если Вы за них выйдете — решение задачи не имеет смысла. Что делать?

                                            3. У Вас N команд, каждая занимается своей областью. Итоговый продукт — совокупность результатов работы всех команд. Некоторые вещи можно делать внутри команды, некоторые основываются на результатах работы смежных команд. У всех поток. Команда 1 приступает к выполнению задачи, которая зависит от артефактов работы команды 2. Но у тех был поток и они еще не сделали. Хорошо, команда 1 делает что-то другое (менее важное и не приоритетное). Команда 2 доделала, что хотела и начала делать что-то другое. Команда 1 тоже доделала свое не такое важное дело, вернулась и поняла, что есть вопросы (нужна помощь с тем, чтобы разобраться, как работают артефакты команды 2). Но команда 2: уже куда-то переключилась, забыла в чем там было дело, да и из потока выходить тяжело — идет другая задача. Не понятно, как синхронизировать работу N команд если мы отказываемся от планирования?

                                            4. Похоже, что методом потока убирает критерий «скорости» при выборе решений. Многие задачи можно решить большим количеством разных способов, например: в процессе реализации разработчик решил, что новую функцию можно встроить в существующую кодовую базу (чего он делать не любит, потому что «там надо разбираться», «legacy» и т. д.), а можно все переписать, чтобы было красиво, удобно и так, как он захочет. И программист выберет второе. Мы же не спрашивали у него сроки, он ничего не обещал нам, вопрос случился уже в процессе работы и он исходя из тех данных, что у него были выбрал то, что считал лучшим решением, при этом увеличив время реализации в 5-10 раз. Как выбирать решения на основе скорости их реализации, когда мы не оцениваем сроки?
                                              –4
                                              если я не знаю, сколько уйдет времени на каждую

                                              А этого никто не знает, если задача не конвейерная.

                                              Что делать?

                                              Использовать более подходящий под ситуацию метод организации. ;)

                                              Как выбирать решения на основе скорости их реализации, когда мы не оцениваем сроки?

                                              Если основным параметром оценки результата является скорость его достижения, и другие параметры не учитываются или малозначимы, то очевидно, что тоже надо использовать более подходящий метод организации. Не просто так существует фраза: «Искусство управления».
                                                +3
                                                Но автор подтвердил, что он:
                                                готов прийти в коллектив разработчиков и за деньги сделать x2 продуктивности

                                                А не:

                                                готов прийти в коллектив разработчиков и за деньги сделать x2 продуктивности, если его метод подходит этому коллективу, а если не подходит то там дальше искусство и может не x2, а x0.5 получится, как пойдет.
                                                  +1
                                                  И что не так? Даже я смогу увеличить продуктивность в два раза, на короткий срок )
                                                +2
                                                1. Не передергивайте. Требуют точных сроков, примерные скажут всегда с легкостью.
                                                2.
                                                Вы знаете, о каком потоке идет речь?
                                                Это состояние часто описывается исследуемыми как ощущение получения удовольствия от самореализации, повышенной и обоснованной уверенностью в себе, ярко выраженным повышением коммуникативных способностей, умением чётко и ясно выражать свои мысли, убеждать собеседника, эффективно решать проблемы любой сложности или находить неординарные способы их решения. У исследуемых в потоковом состоянии повышаются показатели усваиваемости информации, активизируется память, способности к анализу информации, наблюдается лёгкая форма беспокойства, в связи с повышенной активностью.

                                                3. Вы не знаете, о каком потоке идет речь и вовсю упражняетесь в остроумии.
                                                4. У задачи два критерия — правильность решения и эффективность выполнения.
                                                О какой скорости вы говорите? Я могу принять своевременность исполнения, это больше похоже на
                                                деловую дискуссию, а не на выжимки из манагерских книжек
                                                  +2
                                                  1.1 Возможно я и правда чуть передергиваю в своем вопросе. Считаю что такая эмоциональная окраска уместна.
                                                  1.2 Про примерный срок: нет, автор явно пишет:
                                                  … отсутствует их причина – планирование работы программиста и попытки, так или иначе, оценить сроки исполнения работ ...
                                                  под так или иначе я понимаю что в подходе автора сроки никак не оцениваются. Я бы не стал писать комментарий, или писал бы совершенно другой, если подход подразумевал примерную оценку сроков. Но он основан на полном отсутствии оценки, что вызывает вопросы.

                                                  2. То определение, которое дали Вы — это определение потока как психического состояния. В статье термин поток употребляется в другом смысле, как один из методов планирования. Я сделал такой вывод из следующих фактов:
                                                  • Автор сам дает определение этому методу:
                                                    Поток – это когда есть только скорость. Задачи выстраиваются в очередь, программист садится и решает одну за другой.
                                                  • Автор дает классификацию методов планирования, в которой поток ставится в один ряд с такими методами как Lean, Scrum

                                                  Как мне кажется очевидно, что в статье описан поток, как метод планирования, а не как психическое состояние. Но, возможно, я сделал неправильные выводы.

                                                  3. Возможно. Свои предположения по этому поводу я описал в п. 2.

                                                  4. Да, своевременность исполнения подходит как критерий к тому вопросу, который я описал, спасибо. Но это не отменяет вопроса — если я не оцениваю сроки, я не могу оценить задачу по этому критерию.
                                                    0
                                                    Вся суть — не просить специалиста оценивать время на каждую задачу. Оценкой должен заниматься менеджер. Как? По средней скорости выполнения. Где её взять? Очевидно что экспериментальным путем.

                                                    И, я думаю, автор имел ввиду «поток», как организацию работы, а не как состояние работника.
                                                      +2

                                                      Задачи могут различать по трудоёмкости на порядки. Буквально — от нескольких минут до месяцев и лет. А от трудоёмкости зависит и приоритет, и даже сама необходимость задачи.

                                                        0
                                                        Это хорошие три утвердительных предложения. ;)
                                                          0
                                                          Вот тут как раз надо учиться декомпозировать задачи на приблизительно равные по трудоемкости. Чисто интуитивно.
                                                          И если мы говорим не про одну задачу, а про поток задач — даже существенные выпадения небольшого процента задач по трудоемкости мало повлияют на общую картину.
                                                        0
                                                        1.1 Одно давит, второе нет.
                                                        1.2 Никто не спланирует работу специалиста лучше него самого.
                                                        Сроки соответственно.
                                                        2. Время положительной работы равно времени работы.
                                                        Идеальная эффективность.
                                                        4. Специалист вам оценит, каждый свою часть работы делает
                                                      +1
                                                      1. Да, вот, со сроками непонятно. От них ведь зачастую и приоритет зависит. Грубо говоря, есть 4 задачи одинаково важные для бизнеса (читай предположительно одинаково увеличивающие прибыль или иные целевые бизнес-метрики). Если вообще никакой оценки сроков или точнее трудоёмкости нет, то вообще без разницы получается. Но по факту одна заняла час, другая — неделю, третья — месяц, четвёртая — год. А Если в этом порядке делать, то заметно больше можно денег заработать, а если в обратном...
                                                        0
                                                        Наоборот, всё кристально ясно описано. Вы – руководитель, вы и оценивайте, за какое время ваш программист или команда программистов сделает задачу. А их не трогайте.
                                                          0

                                                          Пальцем в небо оценивать?

                                                            +1

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


                                                            Но обычно у хорошего руководителя работы есть как минимум:


                                                            • информация о навыках членов команды и оценка производительности их работы на основании предыдущих проектов/работы в текущем проекте.
                                                            • релевантный опыт работы исполнителем решаемых задач и собственный опыт оценки сложности тех или иных задач.
                                                            • полномочия определять цели и рамки задач и дробить их на такие, трудоемкость которых проще оценить.
                                                        +2

                                                        На счет пункта 1 — действительно не понятно так как тут есть только оценка.


                                                        1. Тут необходимо все-таки договориться с человеком о контрольных точках, мол свяжись при достижении прогресса в 20% 40% 80% и покажи промежуточный результат.


                                                        2. Обычно в таких случаях создается рабочая группа по одному человеку из команды 1, 2, n и они являются носителями знаний об артефактах работы.


                                                        3. Тут от продукта зависит:



                                                        Если он разовый — тогда все делаем как придется но после релиза продукт отработал свой срок и должен быть утилизирован (не стоит мучить труп) и исполнителя предупредить — мы сейчас это сделаем, оно поживет n месяцев и потом все — проект окончен.


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

                                                          +7
                                                          1 Как вычислить эти сроки? … мы же отказались от того, чтобы считать сроки на каждую задачу

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


                                                          2 … нанимаете фрилансера. Час его работы стоит 100$. Вы описываете задачу, и, наверное, хотите узнать, сколько он будет её делать.

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


                                                          Но. Есть нюанс. Его продуктивность как разработчика это всё-равно портит. Поэтому и существуют два типа проектов на фрилансе — fixed cost и time&material (почасовка). И поэтому описанная Вами проблема на практике обычно решается следующим образом: Вы начинаете работать с фрилансером, получаете какие-то промежуточные результаты за какое-то конкретное время и деньги, оцениваете устраивает ли Вас такая скорость, стоимость и качество работы, и либо расслабляетесь и позволяете ему спокойно творить в потоке дальше, либо расстаётесь и находите другого фрилансера. Иными словами, если нужна нормальная продуктивность — вариант с фрилансером сводится к тому же самому: поставьте задачи, получите оценку относительной сложности, и не мешайте работать.


                                                          3 Не понятно, как синхронизировать работу N команд если мы отказываемся от планирования?

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


                                                          4 Мы же не спрашивали у него сроки, он ничего не обещал нам, вопрос случился уже в процессе работы и он исходя из тех данных, что у него были выбрал то, что считал лучшим решением, при этом увеличив время реализации в 5-10 раз.

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


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

                                                            +2
                                                            Мы не спрашиваем программиста сколько часов/дней уйдёт на задачу, но мы спрашиваем его какова относительная сложность этой задачи в попугаях.

                                                            А что вы понимаете под «попугаями»? По-моему, это те же яйца :) Если я правильно понял автора, его подход позволяет программисту избавиться от ответственности за названные «сроки/попугаи» и не думать о них.
                                                              0
                                                              Если я правильно понял, то «сложность» ≠ «время выполнения задачи». Это скорее оценка величины вероятности правильной оценки времени выполнения задачи. Жесть какая получилась, но не знаю как проще сформулировать.
                                                              Вот пример из моей деятельности (я не программист) — надо нарисовать сет из 100 иконок для проекта и разработать лого для него. Я скажу, что и то и то займет неделю. Но по сложности эти задачи различаются на порядок. Потому как в случае с логотипом очень много и явных и скрытых «но» и «если».
                                                                0

                                                                Вообще что такое попугаи относительной сложности описано довольно неплохо и много где, но могу пересказать своими словами. :)


                                                                Смотрите:


                                                                • Почему именно относительная сложность. Очевидно, что джун и сениор сделают одну и ту же задачу за (иногда — сильно) разное время. Соответственно, если оценку в часах привязывать к задаче без учёта того, кто её будет делать — получается уже слишком большая погрешность (по сути — в разы). А относительная сложность задачи от исполнителя не зависит.
                                                                • Почему именно попугаи. Если спросить разработчика "за сколько сделаешь таску" и он назовёт "4 часа" — это обеими сторонами воспринимается как commitment, и начинает "нависать" над разработчиком, напрягать его — со всеми вытекающими последствиями для его продуктивности. А вот если спросить "насколько эта задачка сложнее вон той" — он ответит "раза в 2-3" не напрягаясь, потому что никакого commitment здесь нет, по крайней мере он этот ответ не воспринимает как обязательство делать эту задачу не дольше чем в 3 раза относительно первой.

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


                                                                • Относительная сложность задачи 1: 15 мин — 2 часа
                                                                • Относительная сложность задачи 2: 3-4 часа
                                                                • Относительная сложность задачи 3: 5-8 часов
                                                                • Относительная сложность задачи 5: 2 дня
                                                                • Относительная сложность задачи 8: 3-4 дня, но лучше бы декомпозировать

                                                                Дальше, как только он перевёл эти оценки в часы — они сразу стали зависеть от того, кто будет этой задачей заниматься (сениор/мид/джун), есть ли у него опыт с задачами такого типа, etc. (Цифры выше приведены для сениора либо имеющего опыт в задачах такого типа миддла, для джуна эти часы надо умножать на 2-3.) И чтобы влияние этих факторов нивелировать на помощь приходит статистика: сколько в сумме (складывая значения относительной сложности, а не часы) попугаев закрывает данная конкретная команда за неделю. Если команда состоит из сениоров и крепких миддлов — цифры обычно примерно сходятся, в смысле указанные мной выше в сумме дадут по 30-40 рабочих часов на члена команды (30 — потому что задачи же всегда недооценивают, и по факту они немного сложнее, чем были оценены).


                                                                Конечно, тут не всё прям так линейно. Задачи сложностью 8 можно давать только сениорам и очень хорошо знакомым с задачами такого типа миддлам, если её дать джуну он может уйти в аут на три недели и не сделать в результате. Если у нас пачка на 20 задач сложности 1 — они будут сделаны намного (в разы) быстрее, чем 10 задач сложности 2.


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

                                                                  0

                                                                  Я честно говоря не понял в чем отличие той же оценки в store points, которую рекомендуют в agile. Там даже методика есть как их превращать в реальные сроки.

                                                                    0

                                                                    Ни в чём, это она и есть. То, что я описал выше — немного упрощённый вариант, когда оценку даёт один разработчик на конкретную мелкую (после декомпозиции) таску, которую вполне возможно он и будет делать. Вариант в Agile подразумевает скорее коллективную оценку более крупной бизнес-таски, которую оценивают всей командой (planning poker). Но суть оценки та же — относительная сложность задачи. Только там и масштабы цифр немного другие, бизнесовая задача сложности 1 — это обычно 2-3 дня работы, потому что она включает какой-то мелкий фикс на бэке, соответствующую правку на фронте, ручное тестирование и выкат, со всеми прилагающимися коммуникационными задержками в процессе.

                                                                      0
                                                                      А откуда вы взяли что в Agile не надо декомпозировать задачи на более мелкие? Точно так же надо, если вы хотите долбится каких то приемлемых оценок.
                                                                      Получается что разница лишь в коллективной оценке? Так она там не спроста была придумана, так как один человек не всегда сможет адекватно оценить задачу. Оценка командой повышает точность в виду разной квалификации и опыта разработчиков в команде.
                                                                        0

                                                                        Я не сказал, что не надо декомпозировать. Просто там результат декомпозиции — это всё ещё относительно крупные задачи, потому что это всё ещё бизнес-задачи. Перед тем, как ими можно будет заняться конкретным исполнителям бэка/фронта/тестировщикам/девопсам эти задачи потребуется декомпозировать на ещё более мелкие.


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


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

                                                                  +2
                                                                  1. А почему точность оценки сложности у программиста будет выше, чем точность оценки сроков? И какая разница спрашивать сколько в часах или сколько в попугаях, если перевод из одного во второе осуществляется умножением на константу?

                                                                  2. Соглашусь с Вами, этот вопрос наверное неуместен. Фрилансер должен быть сам себе менеджер.

                                                                  3. и 4.
                                                                  Я согласен с Вашими доводами. Но это очень сильно похоже на scrum, но только без спринтов. Главный вопрос: в Вашем описании сроки все таки есть, мы от них не отказываемся, чтобы планировать, чтобы следить за результатом и пр. Но мы скрываем эти сроки от разработчика. И для разработчика происходит именно то, что и должно по закону Паркинсона (в том виде, в котором этот закон представлен в статье) — задача займет столько, сколько на неё есть времени, а время оказывается не ограничено и задачи перестанут завершаться совсем.
                                                                  То есть моя мысль: или закон Паркинсона не работает, или он работает, но тогда отсутствие ограничения по времени для разработчика должно превращать все задачи в бесконечные.
                                                                    –1
                                                                    1. А почему точность оценки сложности у программиста будет выше, чем точность оценки сроков? И какая разница спрашивать сколько в часах или сколько в попугаях, если перевод из одного во второе осуществляется умножением на константу?


                                                                    В том то и дело, что не на константу. Пример «попугаев» в оной из команд:
                                                                    • Задача может иметь одну из следующих оценок в попугаях: 1-2-4-8
                                                                    • Программист в среднем в неделю (5 рабочих дней) вырабатывает 20 попугаев
                                                                    • Задач сложностью в 1 попугай можно сделать 5-8 штук в день
                                                                    • Задач сложностью в 2 попугая можно сделать 3-4 штук в день
                                                                    • Задача сложностью в 4 попугая делается в течении одного или двух дней
                                                                    • Задач сложностью в 8 попугаев кандидат на декомпозицю или делается 2-3 дня
                                                                      +2
                                                                      В чем принципиальная разница спрашивать у разработчиков сроки в попугаях или часах? Те же самые 1 час — 2 часа — 8 часов — 2-3 дня. Время, естественно, не точное, а примерное.

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

                                                                      Судя по статье автора — чтобы у Вас не было ограничения по времени. Но тогда и делать одну задачу Вы будете вечно.
                                                                        –1
                                                                        В чем принципиальная разница спрашивать у разработчиков сроки в попугаях или часах?

                                                                        Мне стало понятно из этого ролика:
                                                                        Learn agile estimation in 10 minutes
                                                                        TLDR: точные оценки не точны, относительные точны. Особенность психики.
                                                                        Представьте, что Вы попали в новую фирму, где используются те самые попугаи.

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

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

                                                                        Добавлю, что agile это не только сложно, но в принципе подходит далеко не для всех команд и проектов, чтобы адепты не говорили.
                                                                      0
                                                                      А почему точность оценки сложности у программиста будет выше, чем точность оценки сроков?

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


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

                                                                      Скажем так. Он работает в том смысле, что если разработчика вообще не дёргать, то он даже задачу относительной сложности 2 способен превратить в рефакторинг на месяц-два. Но когда разработчик знает, что если его скорость закрывания задач начнёт слишком сильно отличаться от ожидаемой (см. таблицу соответствия часов и относительной сложности выше), то к нему обязательно придёт тимлид или PM с вопросом "а что, собственно, происходит, где затык?", то задачи в бесконечные уже не превращаются. Более того, разработчики вообще-то должны значительно раньше (как только увидели, что в ожидаемое среднее время для задач такой сложности они точно не вписываются, и срок явно будет сорван не на несколько часов, а на несколько дней) сами прийти к тимлиду и сообщить, что сложность задачи была оценена неверно (что дальше приводит к переоценке задачи, и либо её отмене, либо возврату в бэклог на потом, либо декомпозиции, либо продолжению работы но уже с учётом другой оценки).

                                                                        0
                                                                        Во-первых, оценка сложности выдаётся в более приблизительных 1-2-3-5-8 единицах, нет необходимости выбирать «таки 5 часов или 6?»
                                                                        Я не за оценки времени, но все же слышал что есть вариант выбирать экспоненциальную оценку: 1, 2, 4 часов, 1, 2 дня, 1, 2 недели. И программист не выбирает 5 или 6 часов, 5 или 6 это больше 4-х часов значит 1 день.

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

                                                                            Я вообще давал время согласно логнормальному распределению, например: с вероятностью 50% сделаю за 4 часа, с вероятностью 80% сделаю за 2 дня, с вероятностью 99% сделаю за 2 недели. Но менеджерам это почему-то не понравилось, хотя это явно наиболее приближенное к реальности.
                                                                    0
                                                                    я предположу что вы задаёте все вопросы со стороны менеджера

                                                                    1 кто такие «Мы»? С кем вы собрались делить ответственность за принято решение?
                                                                    как уже писали вы, когда вы уже достаточно долго работаете с разработчиком вы можете примерно подсчитать за сколько он закончит, да есть нюансы, но статистическая выборка по нюансам у вас так же повится. А как именно считать уже ваша зона ответственности по предложенной методике. Если не сходится значит вы что-то делаете не так.

                                                                    2 Если клиент не может обеспечить достаточный бюджет в этом виноват он, а не вы и не программист и в прямой трактовке вопроса он уже содержит ответ. Да задача не имеет смысла.
                                                                    С другой стороны вы как менеджер всегда можете договорится с клиентом(дальше предположение), например позволить оплатить выход за бюджет позже, если он будет

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

                                                                    4. вы путаете понятия, запилить фичу и всё переписать это две разные задачи, программист должен уведомить об этом менеджера.
                                                                    К тому же переписание с нуля протеворечит одному из принципов программирования, который на обычный язык переводится как: Работает — не трож.
                                                                      0
                                                                      1) Берёте статистическое время решения одной задачи, и умножаете на порядковый номер в очереди. Даже если задачи сильно разные по трудозатратам, вы всегда будете примерно знать сроки. Чтобы такое предсказание работало ещё более качественно — задачи должны быть атомарные и декомпозированные, это уже задача тимлида\техлида.
                                                                      2) Фрилансер — это не просто программист, он сам себе ещё и менеджер, так что в данном случае это его задача — давать оценку срокам и стоимости, на основании своих знаний о своей скорости работы над задачами. Если вы его нанимаете для разового проекта — вы вправе ожидать оценки. Если вы его нанимаете на долговременной основе, без конкретных задач, а, например, для постоянной работы над проектом — то вы уже можете сами собирать статистику, тогда возвращаемся к ответу на первый пункт.
                                                                      3) Если N команд независимо друг от друга пилят куски общего проекта — куски должны быть независимы друг от друга. Взаимодействие между компонентами должно быть документировано(и соответствовать документации). В противном случае, независимо от того поток у вас, скрам, канбан, аджайл, водопад или что-то ещё — команды постоянно будут зависеть друг от друга, и оттягивать сроки из за внешних(с точки зрения одной команды) проблем.
                                                                      4) В задаче должно быть прописано выбранное решение. Если программист сам выбрал вариант, увеличивающий время разработки в десять раз, и при этом не удосужился описать это в задаче, этот процесс не был проконтролирован тимлидом, об этом не знает менеджер — мне кажется что-то изначально плохо в процессах. При этом, оценка среднестатистической скорости решения задачи всё ещё доступна — если у вас все программисты в среднем каждую десятую задачу делают в 10 раз дольше из за того что принимают решение провести рефакторинг — то 10 задач у вас решаются за 20 условных единиц времени, и пятая задача в очереди будет готова через примерно 10 средних единиц времени. Улучшить точность можно так же как и в первом ответе — оценка задач тимлидом в условных попугаях, декомпозиция их до уровня атомарных задач в один попугай, и т.д.
                                                                        0
                                                                        В задаче должно быть прописано выбранное решение.

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

                                                                          0
                                                                          1) Тимлид. Если он есть — выбор того, что делать — на его совести.
                                                                          2) Техлид. Опять же, если он есть — он тоже может решить, какое решение в данном случае выбрать. Хотя есть стоит выбор между костылём и рефакторингом, это всё же не к нему.
                                                                          3) ПМ. В ответ на вопрос программиста — фигачим костыль по быстрому и копим техдолг, или у нас есть время нормально отрефакторить?
                                                                          4) Сам программист. В рамках отдельной задачи по ресёрчу. Это если нужно именно выбрать, что и как реализовывать. Если выбор между костылём и рефакторингом — всё ещё лучше задать этот вопрос тимлиду или ПМу.
                                                                      +1
                                                                      Коллеги, просто подумайте над такой вещью, просто подумайте и допустите ее:
                                                                      • Сложность ни как не связана с трудоемкостью или как вы любите со сроками. Вообще, воот совсем ни как, да есть исключения, но это не ваш случай
                                                                      • Срок завершения работы это не дата, это функция распределения вероятности
                                                                      • Если хочется узнать дату завершения работы, используйте статистику. Не спрашивайте людей.
                                                                      • Основная задача менеджера понимать что такое ошибки первого и второго рода
                                                                        и стараться избегать их
                                                                      • В текущих методологиях и фремворках все уже есть. Просто используйте те что вам подходят


                                                                        +1
                                                                        Кажется это все довольно наивно — программист оценку не знает, но можно посчитать статистику и узнать скорость и срок. Чтобы статистику посчитать требуется поток более-менее одинаковых задач. А если есть такой поток, то нужная статистика очень быстро будет в голове у разработчика и он будет давать адекватные оценки что в попугаях, что в часах и в любых других единицах. С другой стороны если ситуация "«блин, да я даже близко не знаю, с чем там столкнусь»" то статистика вам не поможет.

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

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

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

                                                                          Удивительно, что для кого-то это не очевидно.

                                                                          1. Считать сроки это тоже работа. Работа требует времени.
                                                                          2. Работа с постоянными дедлайнами увеличивает стресс, который съедает часть сил сотрудника — его производительность падает.

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

                                                                          Спасает только то, что в 90% компаниях к срокам относятся также наплевательски, как и ко всему остальному — т.е. не уложился, ну и ладно.
                                                                            0

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


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

                                                                              +3
                                                                              Оценку на баг дать не сложно.

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


                                                                              • Баги консистентности (что из-за concurrency, что в СУБД) ищутся и лечатся непредсказуемо неделями.
                                                                              • Баги в сложных алгоритмах — да у меня иногда уходило по паре дней, чтобы просто вспомнить (не понять!) как алгоритм должен работать. При детальных комментариях, хороших примерах и т.п.
                                                                              • Баги расчетов в крупных БД — да даже если понятно что воспроизводить, но привести БД в нужное состояние может занять пару дней. Или недель.
                                                                              • А часто баг-репорт это кейс с прода. Полного доступа нет и не должно быть. Как вопросизводить — а фиг знает.
                                                                              • Баги на специфичном оборудовании (ахаха, через неделю станет ясно, что китайская железка сглючила из-за китайского питания).
                                                                              • Баги в любой сложноотлаживаемой среде (или среда многокомпонентная или, например, ОС)
                                                                              • Баги, требующие для исправления пересмотра архитектуры.
                                                                              • Баги в чувствительной к безопасности компоненте. А теперь баги в чувствительной к безопасности и критичной по производительности компоненте?
                                                                              • Баги в голове багрепортера. Задача со звёздочкой: баги в голове багрепортера, который является главным источником требований.
                                                                              • Баги в апстриме или внешних зависимостях. А если эта зависимость — фреймворк с закрытым кодом?

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

                                                                                0
                                                                                Хм… либо вам очень повезло с багрепортами, либо очень несложная система, либо вы гений.

                                                                                Ничего из вышеперечисленного. Я обычно работаю с микросервисами (что уже сильно уменьшает размеры и сложность каждой части системы и увеличивает изоляцию между ними), с использованием чистой архитектуры (что упрощает тестирование), с хорошим покрытием юнит-тестами и немного интеграционными (что упрощает проверку найденных багов и их исправление), ну и всякое другое по мелочи (напр. документация до кода и генерация кода из swagger.yml/protobuf, ревью кода, CI/CD, жёсткие линтеры, подход defect-free при котором баги не копятся в трекере, etc.). Иными словами — фокус делают хорошо поставленные процессы разработки, а не чья-то гениальность.


                                                                                В большинстве случаев всё совсем не так просто:

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

                                                                                  +1
                                                                                  Ничего из вышеперечисленного.

                                                                                  На самом деле вы просто работаете с достаточно простой системой/системами. Отчасти она простая вследствие ваших действий (микросервисы, чистая архитектура, юнит-тесты, хороший пайплайн, отлаженный процесс), отчасти наоборот — приёмы допустимы потому что система простая.


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

                                                                                  Для кейсов отличных, от тривиальных, эти оценки лично я дать не могу.
                                                                                  Вот пример. В начале 2007 года, на внедрении системы учета в производстве (1С, если любопытно), была проблема. В рандомный момент времени ВСЯ система падала (клиенты, сервер приложений, SQL Server 2005 SP1). Ну ОК, первые раза два никто ничего не понял, но потом при минимальном разборе сразу можно было сказать — всё падает, потому что падает SQL Server — точнее возникает эксепшен 20 северити, кладётся минидамп, отваливаются клиенты и нужно рестартовать сервис. А всё остальное падает прицепом. Критичность — шо пипец, каждый раз больше сотни сотрудников фабрики встают примерно на час. HADRы и прочие кластера не факт, что спасут (да и перейти на них недёшево и не за неделю). Директор фабрики на четвёртый раз, конечно, спрашивает — "Доколе?". Что же ему ответить?
                                                                                  Относительно нормально собрать диагностику получилось разу к седьмому-восьмому (падения не каждый день, конечно). Ну как "нормально" — это был запрос SQL, на котором сервер падал. В выходные получилось воспроизвести именно падение сервера, но на поиск из-за чего возникает этот запрос ушло еще несколько дней. Выяснилось, что запрос генерируется системой при просмотре списка документов с определённым фильтром. Запрос достаточно разумный. То есть падение может вызвать любой пользователь и сделать с этим ничего невозможно.
                                                                                  Пользователей, конечно, проинструктировали, но реально это как на бочке с порохом.
                                                                                  У меня ушло несколько дней на создание минимального репро, который зависел от структуры таблиц, данных в ней и запроса. Через несколько недель уже летом 2007 года MS зарегистрировал ошибку, а с 1С общение было более медленным и реально не в 1С проблема. Тем временем вышел SP2 — в нём тоже сервер падал. Воспроизводилась в RTM/SP1/SP2. На SQL Server 2000 не воспроизводилась, но официально купить его уже было невозможно.
                                                                                  Багу MS исправили только в октябре 2008 года в SP2CU10, через пару месяцев SP3 вышел, а чуть раньше в августе SQL Server 2008 — в нём тоже не было баги, но у него были свои проблемы, да и переход не бесплатный. Пара лет почти.


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

                                                                                    0
                                                                                    какую оценку и в какой момент можно было озвучивать, кроме "это самая приоритетная задача"?

                                                                                    У меня тоже случались похожие кейсы. В частности, есть у меня смутные воспоминания про какой-то баг в MySQL, который то ли я завёл лет 15 назад, то ли нашёл в их трекере уже открытый (после того, как сам доотлаживался достаточно глубоко, чтобы его выявить, и понять, что именно искать в трекере).


                                                                                    Тем не менее, это никак не влияет на возможность дать оценку. Конкретно по Вашему примеру:


                                                                                    • Сначала можно дать оценку "мне надо X часов на изучение логов в момент падения".
                                                                                    • Потом, если по логам ничего не нашлось, можно дать следующую оценку "мне надо Х часов на внедрение дополнительного логирования/включение debug-режимов/etc.". После чего баг обычно ставится на паузу до следующего раза (если у компании полно лишних ресурсов и баг критичный — можно выделить X часов на активные попытки делать всё что приходит в голову с системой в надежде что повезёт вызвать баг).
                                                                                    • Когда по логам стало что-то ясно, то можно дать следующую оценку "мне надо X часов на то, чтобы поднять отдельное тестовое окружение и воспроизвести баг в нём, и потом ещё Y часов на попытки минимизировать количество задействованных в воспроизведении элементов окружения".
                                                                                    • Когда баг зарепорчен вендору и возможность фикса заблокирована — оценка 0, потому что лично мы ничего сделать всё-равно не можем. А если вендор опенсорсный и у нас в компании есть достаточная для фикса экспертиза — то вполне можно оценить таску на багфикс как при обычной разработке, форкнуть и сделать самим, когда до неё дойдёт очередь (правда, тут возникает дополнительный тех.долг на поддержание форка и пропихивание фикса в апстрим, но это другая история).

                                                                                    И так далее. Садясь что-то делать — в голове сначала должен быть план, что именно — а, значит, этот конкретный план вполне возможно оценить. Иногда бывают задачи, когда конкретного плана нет — напр. когда задача хаотично потестировать сервис вручную (чем можно заниматься совершенно любое количество времени, продолжая временами что-то да находить) — в таких случаях обычно оценка ставится не на основе плана действий (ибо невозможно), а на основе имеющихся ресурсов (на тестирование выделяется 2 дня, что найдём за это время — то и починим). Чаще бывают исследовательские задачи, когда нужно изучить неизвестную область, в которой можно копаться неизвестно сколько времени — но и такие задачи без проблем оцениваются: сначала выделяем 2-3 часа/дня на первичное изучение, по результатам которого станут ясны объёмы задачи и получится дать уже вполне осмысленную оценку сколько там ещё надо копать.


                                                                                    В целом, проблема с оценкой чаще всего вызвана тем, что люди садятся работать не очень-то понимая, что конкретно нужно сделать и какой конкретно результат от них требуется, и разбираются с этим вопросом уже в процессе работы. Не надо так делать, сначала надо поставить простую и конкретную задачу, с чётким DoD (Definition of Done) — даже если это задача "понять, какую задачу надо решить" (в особо запущенных случаях бывает и такое, очень редко, но бывает). Тогда и оценивать задачи станет намного проще, и работу работать тоже станет проще.

                                                                                      0
                                                                                      Сначала можно дать оценку «мне надо X часов на изучение логов в момент падения»…
                                                                                      … в голове сначала должен быть план…


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

                                                                                      UPD: Речь шла о критическом баге из предыдущего комментария, когда вопроса «закрывать баг или оставить на потом» не стоит вообще, но применимо и к любым продуктовым «фичам», когда нужно заранее оценить, стоит ли вообще эту фичу добавлять, например, в текущую версию.
                                                                                        0

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


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

                                                                                          0
                                                                                          Так в этом и кроется суть проблемы — типовые баги/фичи оцениваются легко.
                                                                                          Нетиповые, коих большинство в развивающемся проекте (если мы о фичах) или тяжелом легаси (если мы о багах… да и о фичах тоже), оцениваются сложно и только для оценки даже возможности внедрения/фикса требуется от Х до У времени, где и Х и У заранее неизвестны.

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

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

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

                                                                                            На практике все эти проблемы — не совсем проблемы.
                                                                                            С одной стороны, понятие "типовая" фича/баг субъективно и сильно зависит от опыта исполнителя. (Напр. у меня 30 лет опыта, и в своей области бэкенда-микросервисов я крайне редко сталкиваюсь с "не типовыми" для себя задачами.)
                                                                                            С другой стороны, если менеджер тупой либо не имеет опыта в IT и не хочет вникнуть в специфику IT — это его проблема, и не надо делать её своей: кто-то один просто должен уйти, либо менеджер либо разработчик (стандартное правило не работать на плохих проектах).
                                                                                            С третьей стороны, всегда есть альтернативный подход (упомянутый в статье) — резерв. Если менеджер хочет услышать прямо сейчас цифру, которую неоткуда взять — ему называется цифра с достаточно большим запасом, чтобы перекрыть большинство возможных рисков. Она, конечно же, ему категорически не понравится (потому что, будем откровенны, для целей планирования она бесполезна), но другой цифры у меня для него в этой ситуации нет. Если он решит эскалировать эту ситуацию и будет требовать другие цифры или назначит цифру с потолка сам — то ситуация сведется к предыдущей — один из нас должен будет с проекта уйти.

                                                                            –2

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


                                                                            А в остальном с автором согласен, разве что сроки при спокойной работе прогнозировать можно и с небольшой погрешностью.

                                                                              0
                                                                              Там же ежедневные часовые стенд апы

                                                                              Это такой сарказм?

                                                                              +2
                                                                              Это всё известная и грустная история. Есть программист Вася. Вася — хороший программист, умный, трудолюбивый. Он пишет хороший код, решает самые сложные задачи. Вася — лучший в команде и реально двигает продукт вперёд своими решениями. Рано или поздно это замечают — Вася становится тимлидом. Что Вася делает первым делом, как тимлид? Вот ровно то, что написал автор в статье. Становится щитом, зонтиком для своей команды. Защищает её от бреда, льющегося сверху, сбоку и снизу. Команда работает не отвлекаясь, программисты в потоке. Да, они не такие крутые как Вася, но их несколько, они защищены, продуктивность растёт в 2 раза. Или в 4. Заказчик доволен. Программисты довольны.

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

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

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

                                                                                      Ловите методику: никогда такой человек к вам на собеседование не придёт, поскольку с такими скилами глупо идти работать на дядю, надо идти мир захватывать :)
                                                                                  –1
                                                                                  Дико плюсую! У нас небольшой стартап где из HW/SW разработчиков — я и двое чуваков на аутсорсе. Работаем на европейском рынке, по их стандартам и участвуем в программах. А это значит, что по мимо стандартной документации сопровождающей разработку нужно еще писать тонны технических описаний под разными углами и смысловыми оттенками. А там нету четких требований к содержанию документов, в основном все аморфно расписано, что мол нужно все написать так, чтобы у комиссии читающей этот документ сложилось впечатление, что все заявленные цели достигнуты, а технические решения реализованы… и бла бла бла…

                                                                                  И в итоге ты месяц работаешь в «потоке» когда изобретаешь новые подходы к решению технических проблем отрасли, составляешь мат. модели процессоров разомкнутых систем с 2х-3х производительностью с работой по ночам и с перерывами на сон и самое главное — тебе это нравится ибо ты делаешь то, от чего тебя прет и это дает результат!, а потом начинается… Тут надо документик сделать для тех вот чуваков, и потом еще один надо составить… Ну, а кто это может сделать кроме тебя? Ты ж все разрабатываешь и ты в курсе всех нюансов (аутсосреров хер заставишь родить бумажку. Хоть какую), да и больше некому. И документ должен с одной стороны быть понятен очень гуманитарию и очень техническому специалисту с другой стороны.

                                                                                  В итоге ты в течении 2 дней выходишь с потока (пытаешься вспомнить какой сейчас год, кто все эти люди и вообще какая сейчас валюта в обиходе)… Начинаешь составлять какие-то документы по системам которые разрабатывались 2-3 года назад с непрозрачными требованиями по наполнению содержания документов и эффективность предсказуемо падает в 3-4 раза!.. И это все еще нужно вести в project/task management ПО. А потом снова за код/алгоритмизацию/исследования ибо R&D!
                                                                                  Но, когда ты спрашиваешь чтобы нанять в команду Project Managerа!!!1/ Product Ownerа или хотя бы тян, чтобы скрасить серые трудовыебудни — ну, а что они будут делать? Вы сами не можете свои задачи спланировать что-ли?

                                                                                  Много копий было сломано в дискуссиях с руководством о работе программиста… но все сводится к «Ты сначала напиши себе ТЗ, а потом его исполняй, но перед исполнением запланируй разработку всего проекта и тасков, а еще время от времени мы тебя будем дергать на писанину документов не важно чем ты сейчас занимаешся»! Тыжпрограммист, а значит — универсальный солдат :)

                                                                                  Хухх, выговорился. Полегчало. Пойду дальше составлять technical file:)
                                                                                    0
                                                                                    Согласен про работу в потоке. Когда нет внешних раздражителей, когда задачи понятны и знаешь что делать — работа идет быстро и продуктивно. Но мне не понятно следующее: если убрать у программиста сроки, то по тому же закону Паркинсона, он будет тратить все время на одну задачу. Ведь сроков нет, а значит сроки — все доступное время, то есть пока менеджеру не надоесть видеть постоянно занятого программиста и не видеть результатов.
                                                                                    Вот только недавно прочитал статью на тему, что сроки все-таки нужно ставить. Даже самому себе, иначе будешь все время тратить на одно и тоже, так как спешить некуда.
                                                                                    То есть, нельзя давать сроков, но они все-таки нужны?
                                                                                      0
                                                                                      Нужно не ставить сроков, а выработать в программистах понимание, что для того или инного програмного модуля нужно потратить минимум времени. Тогда программист сам будет понимать, что заниматься 3 месяца UART портами не приемлемо и сделает четко то что от него требуют не уходя в самосовершенстование кода.
                                                                                        +1

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

                                                                                          0
                                                                                          Программист может увлечься. Всё-же какие-то сроки надо оговаривать.
                                                                                          0

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

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

                                                                                            Зависит от мотивации и квалификации, у меня был проект который я делал 3 месяца в одиночку. Никто меня не трогал, сроки не ставил. Тех задания не было (два предложения не считаю тз).


                                                                                            Да было программирование ради программирования как на фронте (React + MobxStateTree + Graphql) так и на бэке (TDD, DDD, Layers, Queues, Chanels and Filters).


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


                                                                                            Итог — проект запущен, работал как часы, обрабатывал 65,000 клинетов в день, снял нагрузку с call центра, и каждый месяца приносил компании почти 1 миллион в рублях (мне об этом сообщили уже когда я ушел).

                                                                                              0

                                                                                              Будем экстраполировать по одной точке?


                                                                                              Я понимаю что приятно рассказать свою историю. Но неплохо бы при этом на индустрию не обобщать

                                                                                                0
                                                                                                Ну так это классическая ошибка выжившего ведь.
                                                                                                С тем же успехом, с той же мотивацией и квалификацией в подобных условиях можно завалить компанию на минус «почти миллион в рублях в месяц».
                                                                                                  0
                                                                                                  У меня на работе программист такой. Вообще работает сам, с ним почти невозможно договориться о декомпозиции задач или чем-то подобным. Но оставив его на месяц-два он релизит сервис который 5 человек будут делать дольше. Там правда не будет документации, местами код будет «ой», но все будет рабочее, юнит тестами покрывай, бетонируй и выводи на прод. Да, ошибка выжившего, не все выживут если пошлют менеджеров гулять подальше на пару месяцев.
                                                                                              0
                                                                                              Ну этот феномен довольно легко объяснить. Когда кодер работает не парясь о сроке, он обычно пишет более грамотный и качественный код. Что в итоге сокращает время на отладку проекта. Ведь в результате такой работы кодер практически не плодит багов или правит появляющиеся сразу-же не откладывая их «на потом», чтобы «успеть в срок». Как результат работа завершается гораздо быстрее, за счет уменьшения срока на отладку проекта. Тут стоит вспомнить, что баги лучше править сразу, а не после того как нагородил вокруг них огромный интерфейс и кучу взаимодействий. Потому что некоторые баги могут вынудить с нуля переписать огромную часть проекта. Сам с таким сталкивался. Поэтому да, автор прав, лучше кодеров не напрягать.
                                                                                                –1
                                                                                                Статья хороший манифест о принципах организации работы программистов. Не перегружена деталями реализации, да и не важно есть ли они на данный момент.
                                                                                                  +1
                                                                                                  Первый раз, когда не согласен с Иваном. При грамотном подходе Scrum заработает в полную силу. Скрам-мастер уже должен организовать работу команды и привить соответствующие ценности, чтобы Scrum не превратился в базар. Ну, если не соблюдать их, то и получится, как описал.
                                                                                                  А последнее — это сильно попахивает Канбан. И его тоже стоило бы применять. Я бы даже сказал, пошагово внедрять. И да, как раз этим должен заниматься манагер, чтобы не нужно было попадать в «бутылочное горлышко».
                                                                                                    0
                                                                                                    При грамотном подходе Scrum

                                                                                                    Вы в жизни такое видели? Чтобы не на неделю-две, а надолго.
                                                                                                      0
                                                                                                      Вы в жизни такое видели?
                                                                                                      в точку. Только 1 раз. И то прихрамывало. Все равно что-то выходило из под контроля — как правило воспринималось в штыки из-за недопонимания: «Меня хотят контролировать, а я этого не хочу. Лучше обосрать методику, пока ее не внедрили.» Где-то неприменимо, так как работали люди не над одним продуктом, мало того — в разных стеках технологий или программисты были не софтверы, а «на заводе». Ну и до кучи самодурство в руководстве, которое не знало, чем занять «программиста, который ничего не делает», либо проявить инициативу — внедрить новую модную технологию (но результат, как в «Вычитал. Хочу. Делайте»). Но если внедрять систему по уму, то толк будет.
                                                                                                      PS: Пользуясь случаем, хочу сказать. Иван, ты — крут! Обожаю твои статьи.
                                                                                                        0
                                                                                                        Но если внедрять систему по уму, то толк будет

                                                                                                        Вот. А раз по уму никто не умеет (по факту), то — просто посадите в поток, отойдите и не мешайте :)
                                                                                                      0

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

                                                                                                        +1
                                                                                                        неправильно выразился. Спасибо, что поправили.
                                                                                                      0
                                                                                                      «Гладко было на бумаге, но забыли про овраги.»
                                                                                                        0
                                                                                                        Плюсую за защиту состояния потока у программиста. В компании FunBox, где я работаю, мы к этому стремимся. Во многом помогает ориентация на полностью удалённую работу, когда все коммуникации ведутся максимально асинхронно.
                                                                                                        Мне удалось вырабоать подход к декомпозиции работы, при котором оценки служат лишь инструментом проектирования, но не инструментом отвлечения программиста от работы и наказания за непопадание в них. Мне кажется, что мы нашли разумный баланс. Я описал этот подход в статье habr.com/ru/post/524678/#MercyfulDecomposition
                                                                                                        Будет очень интересно узнать Ваше, nmivan, мнение и мнение читателей Вашей статьи.

                                                                                                        Ключевой пункт, в котором мы с Вами расходимся, это отношение к закону Паркинсона.
                                                                                                        Я считаю его неуместным в отношении креативной деятельности.
                                                                                                        Когда возникает впечатление, что в конкретной ситуации закон сработал, то это нужно рассматривать как несчастный случай, а не закономерность. Я рассматриваю это как иллюзию.
                                                                                                        В статье я более развернуто об этом пишу в разделе habr.com/ru/post/524678/#AboutBoundaries

                                                                                                        После статьи есть голосование о законе Паркинсона.

                                                                                                        Заранее благодарю за внимание!

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

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