Предвосхищая возгласы (всем, конечно же, не пофиг) вида:
- Да у вас бардак и все делают что хотят, ужас, так жить нельзя!
Скажу вот что. Я считаю, что в хорошо организованных системах максимум решений принимается на минимально возможном уровне иерархии. Мало того, в таких системах есть тенденция к уменьшению уровня принятия решения. Есть и ошибки, но на них научатся, а люди станут уже чуть менее инфантильными. Именно поэтому работа не по официальному беклогу не всегда бардак и разврат. Иногда это гибкость системы умение принимать правильные решения на местах.
Итак, сам текст:
Представим, у нас есть внутрикомандная-внутрипроектная рабочая задача. Для определенности допустим, что задача эта — написать код. Чтоб предельно ограничить варианты, положим, что мы искренне верим в то, что эту задачу делать нужно.
Казалось бы, в нашем мире не так много выходов из этой непростой ситуации. Один? Два?
Я попытался вспомнить свой опыт <s>партизанского менеджмента</s> и вот что вышло.
Первое, что приходит в голову
Сделать задачу самому
Начинать учиться программированию стоило лет пять назад, но некоторым повезло и они успели заняться этим полезным делом.
Аргумент нет времени не имеет смысла. Во-первых, времени у всех по 24 часа в сутки, а значит надо говорить о приоритетах, а третье допущение говорит, что задача важна для нас.
К тому же у каждого есть масса времени личного, большая часть из которого бездарно тратится на сон. Почему не пожертвовать им?
Попросить менеджера положить задачу в беклог
Чтоб задачу официально сделал специально обученный программист в рабочем порядке. Во многих командах щедрые менеджеры говорят, что выделяют минорным (не умеющим кодить) ролям по одному слоту во время планирования. Половина даже не врет.
Сложность: победить остальных желающих пролезть в этот слот, а затем защищать его от внезапных срочных задач.
Недостаток — придется долго ждать.
Личные истории
Перед отпуском
Перед отпуском программисты не любят брать огромных задач, так что если ваша не такая большая, то добро пожаловать.
Сделать плохо самому и показать специалисту
Для эстетов: заменим плохо на прототип.
Нормальный программист согласится и быстро проведет ревью, а, увидев что-то ужасное, с удовольствием как минимум посоветует, а, скорее всего, отрефакторит до приличного состояния. К тому же, ваш "прототип" будет лучшим источником требований, чем любое ТЗ в виде букв, которые надо читать.
Заинтересовать и продать задачу
Не так просто, как кажется. Рецепт такой:
- Находите в проекте фулстека, который за выходные может переписать сервис, а за месяц половину продукта.
- Полтора года показывайте класс, заслужите уважение этого человека.
- Общайтесь с ним на рабочие темы, показывайте свою заинтересованность.
- В случае, если он помогает — отмечайте это в публично, в идеале многочисленные акты помощи должны быть зафиксированы в полугодовых итогах.
- Если он просит помощи или консультации — бросайте всё и делайте с высоким приоритетом и качеством.
Готово, у вас есть человек, который может сделать любую задачу. Хотя это уже намного менее ценно по сравнению с хорошими рабочими отношениями, которые вы построили.
Добавить вагон
Выполнить задачу вместе с любой официальной большой задачей. Можно использовать дар убеждения, небольшой размер довеска.
Экстремальный, но рабочий вариант — шантаж запретом на релиз. Например: мы не будем релизить с красных тестов. Иногда прокатывает.
Командные истории
Командный выезд
У него есть рабочая часть и туда можно продать что-нибудь своё.
Субботник
Если ваша задача попадает под определение задолбало всех, но не является чьей-то личной ответственностью, то это хорошее решение.
На субботники часто берут борьбу с нестабильными тестами и увеличение покрытия. Можно продавить даже регулярные.
Сюда же отнесу всякие предпраздничные движухи типа предновогоднего соревнования "кто закроет больше мелких дефектов" и прочих "чистых дней".
Стажеры
Слабый, но рабочий ход — предложить свою задачу стажеру-программисту. Делать её будет, конечно, стажер, но ревьюить-то будет вполне себе сильный программист.
Сильный ход — убедить тимлида, что обучение новичка должно состоять обязательно из знакомства с тестирующей системой (или любой другой областью ваших интересов). А знакомиться лучше всего дорабатывая.
Стажировка
Входящая, очевидно. Не самый быстрый способ.
Метауровень
Поставить полугодовую цель
Для этого стать как минимум тимлидом, а лучше — функциональным руководителем. Плюс — огромный ресурс. Минус — конфликты за этот ресурс с теми, кто выбрал следующий способ.
Стать менеджером разработки
Сделать весь этот праздник своей профессией и пытаться упорядочить разработку, которая стала непредсказуемым бардаком из-за тех, кто использует способы выше.
P.S.
Что я упустил? Ваши версии.
Комментариев нет:
Отправить комментарий