5 классных вещей в процессах американской компании

Хочу поделиться интересными и полезными приемами в организации процессов компании в США. Я 9 лет работала в одной продуктовой компании, с момента окончания института, там было много хорошего, но мне с какого-то момента стало интересно «а как у других?». Примерно 8 месяцев назад мне постучался HR и позвал на собеседование в проектную компанию на позицию DBA для работы на компанию из США. В этот момент я работала на позиции заместителя технического директора. Такое предложение было довольно неожиданным, я не отнеслась к нему серьезно – посмотреть как у других хотелось, но не с таким резким снижением в карьере. Но, я согласилась прийти на собеседование – интересен был процесс.



Было 3 этапа собеседования:
  • С ведущим разработчиком проекта в компании-нанимателе
  • С ведущим разработчиком из компании-заказчика (уже на английском)
  • С архитектором в компании-заказчика

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

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

1. Scrum


Сама методология с ее плюсами и минусами заслуживает отдельной статьи. Пока только скажу, что разработка делится на «спринты». Каждый спринт 2 недели. Предполагается, что все задачи будут закрыты за этот срок. Если вдруг, кто-то быстрее справится со своими задачами на спринт, то он подключится и поможет тем, кто не успевает. Оценка сложности задачи, на мой взгляд, очень полезная штука, проводится коллективно. Есть созвон 1 раз в неделю, в течение которого команда обсуждает еще неоцененные задачи и присваивает сложность – на закрытом голосовании. Потом, когда все проголосовали, уже видно, кто и сколько поставил, если есть большие расхождения в оценке — люди, которые оценили задачу, высказываются и обсуждают. В итоге группа приходит к общей оценке задачи. Штука длительная (редко занимает меньше 2-х часов), но, на мой взгляд, полезная. Во-первых, все в курсе основных задач. Во-вторых, такой метод позволяет более объективно оценить сложность и объем задачи.

2. Demo для руководства каждый спринт


Не знаю, насколько часто встречается проблема, когда руководство компании не понимает, что делают программисты. В моей первой компании это был наболевший вопрос. Мы пробовали всякие отчеты, которые в итоге руководство не читало, в итоге вопрос повис, а непонимание осталось. А было такое простое решение. Презентация — раз в 2 недели (здесь по окончанию каждого спринта) с кратким обзором того, что было сделано понятным для бизнес-людей языком. Это дает руководству понимание, чем заняты люди и возможность понять туда ли движется проект.

3. All hands meeting


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

На таком «созвоне» обычно присутствует вся компания. И у всех есть возможность задать вопрос в эфире. Длится примерно 1 час. Проводится 1 раз в месяц или в квартал, в зависимости от компании.

4. Code review


Это больше техническая часть, но тоже очень полезная. Организация применения изменений в первой компании была следующая: разработчик вносил изменения, тестировал, отдавал тестировщику, затем следовала обязательная часть с подробным code review со стороны руководителя. Далее руководитель уже применял изменения к работающей системе. Мы не могли придумать как избавится от части с просмотром кода. А решение очень простое – code review должны делать сами разработчики. Только не тот, который писал код, а 2-3 других человека. Все их комментарии и замечания должны быть внимательно изучены и применены, либо автор-разработчик должен убедить своих коллег, что его решение лучше. Один момент – разработчики должны быть мотивированы делать code review. Иногда ожидание получения отзыва от других занимает столько же времени, сколько сама задача, а потом возвращаться к уже написанному коду и править его неудобно.

5. Bridge call во время проблемы


Если случается какая-то непредвиденная ситуация, например, загрузка ЦПУ на рабочем сервере возрастает до 90% и не удается в течение 5 минут устранить эту проблему, организуется Bridge call специалистов компании. Присутствуют DBA и ведущие разработчики.

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

Надеюсь, мой опыт будет вам полезен.
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 48

    +6
    Зам техдира не знает что такое scrum и удивляется демо?
      +1
      Ну почему сразу не знает? Scrum скраму рознь. Многие просто не умеют его готовить. А demo во многих компаниях быстро превращается в формальность и умирает.
      Вопрос в том, чтобы заставить все эти полезные штуки работать (и тогда в них поверят и к ним подключатся разработчики).
      Автор как раз пишет про процессы и как они настроены в его новой компании.

      Автору: Спасибо, было интересно прочитать. Надо продолжать делать demo. :)
      Помимо продолжительности, какие еще проблемы с покером планирования у вас были?
        0
        Спасибо, рада что интересно.
        С покером еще был следующий момент, если человек не разбирается в задаче и это не его область ему обычно сложно оценить сложность, тут обычно видно по голосованию — если все хорошо объяснено оценки довольно кучные. Оценки сильно отличающиеся от остальных как правило показывают, что человек, который их ставил не понимает как делать задачу.
          0
          Ну почему сразу не знает? Scrum скраму рознь. Многие просто не умеют его готовить.

          Потому что достичь достаточно высокой должности и не увидеть как его готовят в ай-ти надо ещё очень сильно постараться.

          P.S. Лично я scrum не люблю. Но некоторые вещи вполне себе используются.
          Достаточно вспомнить старое слово «планерка»
          +1
          Про scrum: одно дело знать о том, что это и совсем другое видеть как это реально используют.
          Про демо: думаю нужно небольшое углубление. Понятно, что при изменении интерфейса программы или добавления новых функций их легко показать. Так как первая компания была продуктовая там большую долю времени занимала оптимизация работы системы. И вот осознания, что это тоже можно показывать на демо не было. А оказывается можно, на пальцах, высокоуровневым языком, но можно.
            0

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

          +2
          А про минусы, пожалуйста
            0
            Поддерживаю!
              0
              Хочу написать, только не в виде прямо минусов. На мой взгляд неэтично критиковать компанию «за глаза». Хочу собрать проблемы в управлении, с которыми сталкивалась и описать.
              –1
              Все программисты драпают с all hands, ну или пасьянс раскладывают, если встреча удаленная.
                0
                Есть такая проблема. Мне кажется это от того, что люди не понимают зачем им эта информация, у них не возникало в ней нужды, а им ее уже дали.
                Мне all hands очень нравится, я рада, что они есть. Можно провести параллель с бегущим отрядом и его командиром. На all hands командир периодически говорит, например «Эй, ребята, я бегу на Север, буду искать клад старого Джо, мне нужна будет помощь в поиске и раскопках.» И я могу для себя понять — хочу ли я туда, интересно ли мне это, насколько я считаю интересным и правильным бежать и раскапывать клад Джо. В общем я рада, что эта информация у меня есть.
                  0
                  Очень печально когда зам. техдира в описании процесса применяет такие слова как «мне очень нравится»

                  Это не критерий для оценки эффективности workflow
                    +1
                    Спасибо за коммент. У меня часто рождается именно ощущение — хорошо, нравится, и если покопаться оно чем-то обосновано. Тут поделилась больше эмоциональной частью, и после вашего комментария, поняла. что не хватает собственно почему я считаю это полезным.
                    Чем на мой взгляд хороши all hands meeting?
                    • Повышения прозрачности со стороны руководства для сотрудников. Как следствие повышение доверия. Озвучивания целей и курса компании дает возможность человеку следовать этому курсу осмысленно, видя цель, больше вероятности, что к ней придешь. Это инструмент распространения видения цели на всю компанию. Сам каждый решит будет он лично двигаться к этой цели или нет, но знать о ней он по крайней мере будет.
                    • Формирования у разработчиков общей картины, видения происходящего. Я сталкивалась с такой проблемой – продукт разросся и разработчик пилит какую то маленькую часть, но при этом что вокруг нее не представляет. Нет понимания бизнес процессов и потребностей клиентов, на мой взгляд all hands способствует формированию общей картины.
                    • Возможность непосредственно пообщаться с руководством компании. Иногда у человека зреют какие-то вопросы, которые хочется задать собственнику (или директору) компании, но возможности это сделать нет. All hands такую возможность предоставляет.

                      0
                      Да это собственно не мне.
                      Пользу от этого типа совещаний я знаю.

                      Вы в статью писать не забывайте :)
              –1
              С подлючением! И это стоило статьи?
                +1
                Спасибо!
                Про «стоило статьи» — бывает когда информацией хочется поделиться, и когда уже поделился со всеми друзьями и еще хочется, на мой взгляд, надо пробовать делиться в статье. Это как раз такой случай.
                0
                Bridge call конечно решает проблему, но зачастую прескучнейшее занятие, часто не хватает визуализации (расшаривания экрана) и многие участники не вовлечены активно, поэтому мягко говоря скучают и страдают фигней во время таких звонков.
                  0
                  Визуализации очень не хватает. Особенно в сочетании с отсутствующим доступом это, например, меня доводит. Проблема есть, а сделать что-то с ней я не могу. Вид пытки такой. Как вариант озвучивать те действия, которые бы я сделала в этой ситуации и задавать вопросы.
                    0
                    У нас bridge call (или war room, если всё очень серьёзно) делается одновременно с webex — визуализация присутствует обычно.
                      0
                      TeamViewer не способен от этого спасать?
                        0
                        Неудобно. Чаще используют join.me
                          0
                          Там же нет управления удалённым рабочим столом, чужой мышкой не подвигаешь! Чтоб активно вовлечься…
                      +1
                      Я бы добавил еще один пункт, который присутствует в американских компаниях, это совещание, которое собирают по окончанию проекта и где все участники высказываются, о положительных и отрицательных моментах которые были в проекте, а так же пожеланиях по улучшению работы в будущем.
                        0
                        Да, тоже хорошая и полезная практика. На мой взгляд почти оно же — Sprint Retrospective, только проводится каждый спринт.
                          0
                          lessons learned…
                            0
                            deleted
                            +6
                            Когда же эта ересь со Scrum отойдет в мир иной?

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

                            Итак, по порядку. Stand up meeting. Народ рассказывает, как он классно написал SQL скрипт или что компьютер не имеет доступа к каким-то там ресурсам. Один, якобы, Java разработчик изучает отличия JRE от JDK. Судя по всему, монотонное жужжание некоторых докладчиков и не особо интересно остальным, но традиция должна быть соблюдена.
                            Каждое утро, три идиотских вопроса: Что сделано, Что планируется делать, Есть ли проблемы.
                            Тут настоящий разгул для талантливых с виду натур, можно вступить в бессмысленную полемику или даже повысить значимость своей работы, придумывая на ходу чрезвычайные сложности которые могут возникнуть при создании какого-либо тривиального действа.

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

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

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

                            Тут вступает детальное обсуждение. 15 минут можно смело потрать на обсуждение того факта, как же здорово сделать журналирование работы Java web-сервиса. Бизнес заказчик должен знать все детали сего сакрального действа, другой же части так же нужно всячески показать важность оного.

                            Как итог, 30-40% времени разработчика тратится на звонки, встречи и прочую активность такого рода.

                            Я так и не смог дать ответ, почему дела обстоят именно так.

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

                            И да, минусы от адептов секты Scrum только приветствуются!
                              +1
                              Я во многом согласна, именно поэтому хочу о самой методологии написать отдельно, мои ощущения и впечатления от работы во многом совпали с Вашими. В Scrum понравился именно подход к оценки задач.
                                +1
                                И не надо о ней писать. Чем меньше балбесов знают о каком-то сектантском учении тем лучше нам нормальным котам, которые гуляют сами по себе. Впрочем, даже знание этих бедняг не остановит нас.
                                  +3
                                  Сижу ржу, хочется поделится первоначальным шоком «Нет, правда, правда они тратят на это по 1 часу в день? и 2-3 на груминг в неделю? и еще retrospective и еще sprint planning? А когда работать?» и потом все-таки были положительные моменты, которые можно стянуть и применить с пользой.
                                    0
                                    Для понимания, нужен ли скрам разработчикам или введен начальством в качестве «серебряной пули» — достаточно спросить как оценки времени выполнения задач соотносятся с реальностью и как это соотношение меняется со временем. Если это где-то 0.85-0.9 или растет к этому — скрам помогает. Если же программисты «промахиваются» раза в два и это не меняется месяцами — «что-то здесь не там».
                                    Ну и для продвинутых/наглых — можно поинтересоваться кто ответственен за скрам-оф-скрамс и есть ли постоянный скрам-консультант. Если СОС организует начальство, а консультант торчит в фирме на постоянной основе — ничего путного из этого не выйдет, ритуалы так и останутся ритуалами а время будет бесполезно потеряно.
                                +1
                                Любую идею можно саботировать или довести до абсурда. Скрам — это не методология, а фреймворк, который нужно подстраивать под каждый конкретный случай. В основе Скрама лежит некоторое количество вполне здравых мыслей — что команда способна сама себя регулировать; что двигаться стоит небольшими шагами, чтоб суметь при надобности быстро переориентироваться; что важно добиться понимания всеми того, что делается, в каком виде проект и сколько времени он займет; что в нынешних условиях быстро сделанный минимум лучше опоздавшего на полгода максимума…

                                А элементы методологии нужно применять и адаптировать по назначению. Ну, например, пресловутый Stand-up. Он на самом-то деле нужен не всегда, и не обязательно каждый день. Но идея весьма проста — быстро глянуть на то, что мы, как команда делаем, и что собираемся делать дальше. Никакая полемика и никакое обсуждение проблем не допускаются, stand-up должен занимать минут 10, ну 15 от силы. В некоторых командах это не нужно, там и так все хорошо знают, что делается. А в некоторых нет хорошего контакта, и получается кто в лес, кто по дрова.

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

                                Вам, похоже, просто не повезло, и вы не работали в месте, где такого рода методология по-настоящему успешно применяется.

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

                                  +1

                                  Чтобы собрания любые, не только stand-up не были бесполезными требуется человек, который следит за обсуждением и прерывает не относящиеся к делу ветки. Сам Stand-Up происходит за 15 минут и при нормальном размере комманды 5-8 человек каждый должен высказаться, а это 3 или меньше минут на человека — не заскучаешь.


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

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


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

                                  Это показатель того, что product owners — не знают как правильно писать user story. Задача для scrum master — их научить. Если последний не видет этого или ничего не делает — его вина. Если у него нет достаточных полномочий — вина руководства.


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

                                  Ну во-первых не бизнесс кейсов, а user story. Описание реальной проблемы реального пользователя которое может быть понятно любым членом комманды (пусть после некоторых объяснений).


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

                                  А что там неясного с номерками? С точки зрения разработчика — смотришь на несколько задач A, B, C и D которые ты делал ранее и сравниваешь больше ли задача E, которую нужно оценить, чем каждая из них или меньше — и выдаешь результирующую циферку. Если ты выдал циферку которая сильно отличается от остальных — вы обсуждаете почему ты так думаешь и почему они думают по-другому. Если оказывается что ты учел что-то что они не видели — делается новая оценка, если их доводы оказываются убедительнее — ты можешь поменять свою.


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


                                  5 минут можно смело потрать на обсуждение того факта, как же здорово сделать журналирование работы Java web-сервиса.

                                  Для того, чтобы от этого отучиться надо некоторое время поработать в XP и освоить принцип YAGNI. Пока задача не в бэклоге и не приоритизирована — она не обсуждается. Как бизнесс так и техническая. Задача тех. лида засунуть технические задачи в бэклог и сторговаться с product owner о приоритетах (по большому счету обосновать необходимость решения).


                                  Как итог, 30-40% времени разработчика тратится на звонки, встречи и прочую активность такого рода.

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

                                    0
                                    Когда же эта ересь со Scrum отойдет в мир иной?

                                    Наверное вместе с принципами Стивена Кови ;))
                                      0
                                      А вы не могли бы помочь мне?

                                      Каким образом Кови и Scrum увязаны между собой столь неразрывно?
                                      0
                                      Как итог, 30-40% времени разработчика тратится на звонки, встречи и прочую активность такого рода.
                                      В далёком лохматом 2005 бывший сотрудник компании, где я тогда работал, ушедший в американскую компанию, говорил, что якобы по их стандартам программист должен программировать 4 часа в день. Как я понял, под «программировать»имелся в виду непосредственно кодинг. Чем-то похоже.
                                      0
                                      Не знаю, насколько часто встречается проблема, когда руководство компании не понимает, что делают программисты.
                                      Что-то фундаментально неправильно в такой компании.

                                      А решение очень простое – code review должны делать сами разработчики. Только не тот, который писал код, а 2-3 других человека.
                                      Поздравляю с открытием мира ITIL и одной из его практик — segregation of duties.
                                        0
                                        Все методики по-своему хороши, но каждый пытается на этом заработать подавая под своим соусом (речь о консультантах, которые внедряют это все в компании).
                                        Но на мой взгляд во всех этих митингах и стендапах очень много «воды» и очень мало «делать». Все собираемся кругом, водим хороводы, пожимаем руки и сидим с нахмуренными лбами, в итоге половина рабочего дня, а то и весь уходит в утиль без видимых продвижений.

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

                                        Собственно сам список вопросов:
                                        1. В чем сущность проблемы?
                                        2. Какова причина возникновения проблемы?
                                        3. Какие могут быть решения?
                                        4. Какое решение вы предлагаете?
                                          0
                                          Да, отсутствия структуры собрания порождает кучу проблем и потерянное время, а как следствие если посчитать сколько компании обходятся все участники митинга в час, то можно увидеть, что все это стоит очень дорого.
                                            0

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

                                            +1
                                            Эммммм… вы зам. тех дира и только сейчас узнали про эти вещи?
                                              0
                                              Выше написала ответ на такой же коммент.
                                              –2
                                              Вы б читали побольше чтоли. Меньше откровений было бы при смене работы.
                                                0
                                                Посоветуйте, пожалуйста, например 3 книги самые полезные на ваш взгляд.
                                                0
                                                Запоздалый комментарий. Но все же лучше позже, чем никогда.

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

                                                Потому что работать 8 часов кряду невозможно — ну невозможно физически! Уходит время на отдых, туалет, иногда хочется встать и пройтись, почитать тот же хабр. По оценкам некоторых, на работу в среднем реально уходит до 4(!!!) часов в день.
                                                И вот в таких условиях нам надо оценить задачу А и задачу Б.

                                                Допустим, реальная оценка обеих задач — по 4 часа. Если придерживаться формального подхода, на их решение требуется один день (8 часов же!). Но так как никто реально не работает 8 часов, либо надо завышать оценки всегда, либо выделять официальное время на неработу (что никогда не делается). Именно поэтому разработчики стоят перед сложным выбором — или сказать правду и пахать как проклятые (во имя чего?) или работать нормально, но наврать с оценкой.

                                                Кто может прокомментировать данную ситуацию?
                                                  0
                                                  Формально у вас 40 рабочих часов в неделю.
                                                  Но нормальный менеджер не будет планировать более 28 — 32 часов (если вы lead, то можно планировать еще меньше, если процесс работы с командой не формализован каким-то супер крутым образом).

                                                  «Запасные» 8 — 12 часов — коммуникация, переключения и прочие оверхеды (в том числе habr, мелкие фиксы до 15 мин., месседжеры, почта. ответы на вопросы и т.д.). Не забывайте, что это не отменяет поправочного коэффициента в оценке задач (x1,2 — 1,4).

                                                  В итоге 8 часовые задачи никогда не ставятся на 1 день (всегда на 2).
                                                  + не забывайте, что оценка нужна в первую очередь для обратной связи. Опоздать не страшно (реально сложно учесть все нюансы), страшно никому об этом не говорить до последнего момента.

                                                  Но, возможно, я просто не сталкивался с методологиями, в которых запрещена корректировка оценки. :)
                                                    0
                                                    Спасибо за ответ.
                                                    Полагаю, вы правы, и надо просто закладывать «запасное» время. Просто мне лично никогда не приходилось это наблюдать вживую. Если все решили, что задача на 8 часов (все — это скрам же!), то она всегда ставилась на один день. Наверное, мне просто не попадались нормальные лиды, которые понимали, что 8 часов на задачу не означают 8 часов, проведенных в офисе.
                                                    0
                                                    Если брать конкретно эту компанию, был разговор на одном из митингов, что нужно планировать не более 6 часов в день работы, остальное почта, коммуникации. Как и сказал Loengreen.
                                                    На моей практике, если сравнивать работу без оценки задачи и с оценкой, я точно выберу с оценкой. Пусть даже немного неверной. Общая картина в итоге получается более предсказуемой и прозрачной. Кроме того навык оценки задач улучшается, чем больше оценки, тем точнее она становится (так по крайней мере в идеале). Конечно, бывает, что в середине выполнения вылезет какой-нибудь Кракен и задача займет сильно больше исходной оценки, но это скорее исключение, чем правило.

                                                  Only users with full accounts can post comments. Log in, please.