Несколько соломинок для прокрастинатора

    В конце есть краткое содержание.

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

    Улыбнулись, пока читали? Ну, внутренне хотя бы. Если да, то читайте дальше. Если нет, то выбирайте другую публикацию.

    Вообще, я согласен, что делать надо качественно и в срок. Ну, со сроком только не согласен – крайне редко он вообще что-то значит, кроме отметки в чьем-нибудь календаре. Проверить просто – что будет, если срок просрочить? Если будут потери, то срок имел смысл. Если потерь не будет, то нет.

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

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

    Будем выкручиваться. У каждого человека, который где-то работает, есть свой набор приемов, как избежать наказания (или «наказания») за просрочку. Поделюсь коротенько своими наработками.

    Ночь


    Самое простое, что есть на свете – всегда ставить сроком конец дня. Этим, наверное, все пользуются. Когда срок выпадает на конец дня, то всегда есть ночь, чтобы доделать. Большинству заказчиков ваш результат ни куда не впился на ночь глядя.

    Если задачи ставятся через какую-либо систему, то обратите внимание, есть ли в ней время, или только дата. Если только дата, то классно – можно считать, что дедлайн закукарекает в 23:59:59.

    Пятница


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

    Нечеткая постановка


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

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

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

    Четкая из нечеткой


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

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

    Расширение задачи


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

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

    Два варианта


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

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

    Бартер


    Этим я часто пользуюсь – меняю просрочку на увеличение объема работ без изменения стоимости. Подавляющее большинство соглашаются. Разумеется, если это важно. Иногда бесплатно делаю что-то.

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

    Нечитаемый результат


    Так себе приёмчик, но иногда выручает. Надо сделать так, чтобы заказчик не смог посмотреть результат, а когда он об этом сообщит, сделать удивленное лицо и обещать всё скоро исправить, только вот прям щас не могу, корова телится/кран прорвало/понос случился.

    В институте, например, надо было выслать преподавателю презентацию – взял первую попавшуюся, открыл блокнотом, удалил одну букву и отправил. Так же можно высылать запароленные архивы, и допускать ошибку в пароле (классика – «с» вместо «c»).

    Можно тупо не тот файл выслать. Изменения залить не в ту базу (ну т.е. «ой, я, наверное не в ту базу залил, скоро исправлю, щас корова отелится/…»).

    Правда, этот прием – на один раз для одного заказчика. Второй раз не поймет.

    Соскок


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

    Этот прием тоже не подходит для частого использования. Ну, раз в год, может. Иначе будут считать ненадежным.

    Что-нибудь эдакое сделать


    Эдакое – это когда про задачу просто забудут. Например, сказать, что увольняться хотите. Или просто работу ищете. Или в запой уйти. Или в «запой» — спрятаться, не брать трубку, не читать сообщения в мессенджере.

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

    Да, разумеется, надо какую-то правдоподобную легенду придумать.

    Но вообще, конечно, лучше просто хорошо работать. Решать задачи качественно и в срок. Удачного дня, друзья.

    Краткое содержание


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

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

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

      +10
      потом почитаю.
        0
        Большая часть соломинок более-менее грамотным менеджером, знающим и применяющим 7 парадигм Фридмана пресекается на корню быстро и решительно.
          +4
          О, один мой бывший коллега уехал в Камбоджу отдыхать аккурат за 2 дня до пандемии, и там уже 2 месяца, прокатит под «Что-нибудь эдакое сделать»?
            +2
            Можно делать проще. Не брать ответственность за сроки. :-)
            Делается так:
            1. Спрашивают сроки. Сказать срок «за сколько вы предполагаете сделать» * 3.5
            2. Сразу возмущаются, что так долго. Предлагаете назвать срок, за который хотят чтобы было сделано.
            3. Говорите, что это их срок, и вы за него ответственности не несете. Если получится — хорошо. Нет — сами виноваты, не умеете в сроки.

            4. PROFIT

            P.S. часто помогает «почасовая» декомпозиция задачи. Чтобы обосновать ваш срок.
            Главное не забыть, про тестирование, время на «CI/CD» (если не автоматизировано) и «неопределенность ТЗ».
              +2

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


              С завышением оценок затрат помогает бороться лишь альтернативный исполнитель.

                0
                Ну абсолютно точная не нужна, но для простых CRUD, вполне возможно.
                Например, у так расписал за ~6 часов проект на пол года.
                Но там из ТЗ было понятно какие будут экранные формы и количество элементов на них.
                Так же в принципе понятно, по времени, с интеграцией через soap.

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

                  Сколько контрольных точек в вашем почасовом плане за 6 месяцев было? 1000 или меньше? Каким образом контролировали? По сумме Earned Value раз в неделю?

                    0
                    «Чукча не читатель, чукча писатель». :-)
                    Я не PM, а программист (писатель).
                    Просто PM попросил оценить объем работ и успеем ли мы к сроку.
                    Я прикинул. Посчитал. Получалось, что срок срываем ~3 месяца.
                    Где-то так и вышло. Правда чуть, больше, т.к. там по ходу дела были изменения в ТЗ.
                      0
                      И какой разброс прогноза сроков был: срываем срок ровно на 3 месяца? Или на 74 дня? Или на 73 дня и 7 часов?

                      Я надеюсь, вы увидели, что ваш план вовсе не почасовой. Просто у вас в пакете работ много коротких повторяющихся задач. Но вы не планировали выполнение каждой из них с точностью до часа. Вы планировали весь пакет работ целиком, с общим запасом.
                        0
                        Не согласен с вами.
                        Можно сделать декомпозицию проекта (если это не R&D), до «атомарных» задач.
                        Т.е. тех, которые уже «не делятся».
                        И время для этих задач ~ 1-2 часа.
                        Не ровно 1 час. А можно сделать в течении часа.
                        Ну или не более часа.
                        Вполне нормальная точность. Если оценку по времени наложит на производственный календарь, то можно узнать «приблизительные сроки».
                          0

                          А в чем смысл такой точности? Я понимаю смысл перечня задач, т.е. WBS объединенных в пакеты work package. И понимаю смысл оценки времени исполнения пакетов с точностью до исполнителя: например, этот пакет делает вася 5 дней, маша 10 дней, и по 1 дню вася и дима. И для каждого пакета пригодится оценка даты начала и завершения + запас. В данном примере, допустим 30%. Итого на диаграмме ганта полоса на 13 дней. И, если она окажется на критическом пути, я, имея указанную выше информацию, смогу ее оптимизировать. И на диапазоне в пол года в моем ежедневном плане будет больше тысячи строк. Плюс зависимости, плюс неопределенности. Что даст мне почасовой план? 10 000 строк и еще больше зависимостей? В чем смысл такой точности?

                            0
                            Это нужно программистам, т.к. они «не умеют в сроки».
                            А так хотя бы можно выдать оценку с приемлемой точностью.
                            Для PM не знаю, т.к. с кем я встречался в сроки они не умеет совсем.
                            В лучшем случае спрашивают у программиста.
                            В худшем ставят «палец потолок».
                            Ну и как обычно проект сделан в лучшем случае на половину, а дедлайн подкрался незаметно. :-)
                              0
                              У нас нет противоречий. Программисты не планируют свое время по часам на конкретные задачи. Обычно мы все же планируем сразу целый пакет задач на какой то больший отрезок времени, день или даже неделю. И в этом пакете задач выделяем какие то приоритеты: вот это и вот это буду делать сегодня, вот это завтра, ой нет, не получается, еще почитать надо доку, сделаю пока вот это. И вот тут оказывается, что планировать по часам столь детально смысла нет. Обычно ничего страшного что это не сегодня, а завтра. А сегодня что то другое. Но знать состав работ — опять же важно. Иногда, это помогает сделать более точную оценку, если работы «конвеерные». Но чаще работы «творческие» и в пределах одного исполнителя оценить весь список сразу в днях легче. И проверять проще. И требовать. Хотя, бывают исключения, но они именно исключения.
                                0
                                Это у вас. Где за время отвечают ПМ.
                                Что по моему мнению — правильно.
                                Но я чаще сталкиваюсь ситуацией, когда ПМ просто не умеет в сроки.
                                И перекладывает ответственность за сроки на программиста.
                                Вот тут и приходиться делать декомпозицию, чтобы выжать срок не «палец потолок», а что-то более-менее близкое к истине.
              0
              Как часто в таком случае клиенты повторно будут обращаться? Или об этом не задумываются, решить сейчас и забыть.

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

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