• Борцы с бизнесом

    Posted on December 8th, 2008 Александр Орлов 20 comments

    HPM Reality Show: открытый тренинг проекта Happy PM, 12-15 декабря 2008, С-Петербург

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

    - С каким кодом? – переспросил кто-то.

    - Ну, с говнокодом – нашелся рядом другой специалист.

    На эту тему мне тут же вспомнилась интересная проблема. Среди моих знакомых программистов есть довольно много очень талантливых. На многих из них рано или поздно нападает схожая болезнь. Предыстория у болезни обычно такая:

    • Прочитана какая-нибудь книга (возможно, не одна) о том, каким должен быть хороший код
    • Обнаружено, что код проекта не является хорошим

    После чего болезнь вступает в активную фазуи- программист начинает стучать всеми копытами и говорить о том, что такое г…о, как у вас, никак нельзя выпускать в продакшен. Иначе потом это будет невозможно поддерживать (вариант: невозможно отлаживать; еще вариант: невозможно расширять).

    Иногда это не болезнь, иногда и правда процесс разработки отсутствует, и код плохеет и плохеет. Но иногда с точки зрения продукта – все работает и неплохо, но “код отвратительный”. И все слова менеджера о том, что “бизнес требует, time to market” – воспринимаются как слова врага качественных программных продуктов. “Им лишь бы нафофнячить и выпустить…”

    Меня это неизменно поражало. Казалось бы, это очевидно – бизнес есть бизнес. Раньше вышел – зарабатываешь деньги. Позже вышел – кто-то уже зарабатывает деньги вместо тебя. Но “борцы за качество” борются за качество, а не за деньги. :)

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

    Но в этот раз приходит “борец за качество”. Он сидит час, второй. Ты робко заглядываешь: мол, как там, не близится ли конец работ?

    - Нет, – отвечает борец за качество, – мне нужно тут внутри отшлифовать все винтики, а то, когда унитаз снова сломается, и придет мой коллега, то он может не смочь разобраться, где тут что. И тогда он расстроится и не сможет починить унитаз за 10 минут. Потратит целых 20. Я сейчас, тут недолго…

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

    Где-то к утру, когда бизнес требует уже очень сильно, ты наконец выгоняешь его, и так и живешь потом – с работающим унитазом, но только с половиной отшлифованных винтиков…

    Но смех смехом, а проблема-то есть. Я пришел к тому, что “борцы за качество” появляются в командах, где что-то не в порядке с мотивацией. Может быть, человека не слушают, или не обратили внимания на его идеи, и он таким образом пытается обратить на себя внимание, доходя иногда даже до саботажа. И вот эту проблему придется решать. Может быть, начинать человека потихоньку слушать, но после того, как бизнес будет удовлетворен и будет ждать второго релиза. :)

    P.S. Коллега oldjackaroo кинул старую ссылку, которую я, однако, не видел – про русского, китайского, индусского и канадского программистов. Очень жизненно. :)

     

    20 responses to “Борцы с бизнесом”

    1. Качество должно быть “встроенным”. Борьба за него действительно ничего не дает. Оно может быть низким или нормальным (образцовым оно просто не бывает), но оно должно быть гармоничным следствием действий команды.

      Откуда берутся борцы? Это просто люди, карьерой которых никто никогда правильно не управлял. Либо это уже поздновато делать. Потому преследуется исключительно свой интерес – получить удовольствие/самоутверждение от работы. Выхода два: либо человека преобразовывать (это потребует целенаправленных усилий) или прощаться.

      В профилактических целях менеджеру просто необходимо для всей команды:
      1) предоставлять бизнес-видение; регулярно
      2) в конкретных ситуациях узвучивать бизнес-последствия; позитивные или негативные

    2. Александр Орлов

      Я вот думаю, не развести ли специальную породу студентов, которые будут, например, “бороться” за какую-нибудь хрень типа благозвучность в названиях переменных – чтобы давать этих студентов в подчинение “борцам”. :)

      А по сути – согласен, конечно.

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

      А эта древняя дихотомия – качество/сроки. В Peopleware или у Брукса был описан работающий подход для ее разрешения. Девиз подхода “Quality is free”, или в смысловом переводе “Качество обходится бесплатно”. Основная идея в том, что качеству уделяется должное внимание С САМОГО НАЧАЛА проекта, а не под конец, как в этом посте. Тогда все кажущиеся затраты на качество окупаются слихвой.

    4. 2 Ra:

      Правильно, что качество “начинается” с самого начала разработки. Так и должно быть. В том и дело, что все должны в органичном порыве разрабатывать систему с определенным “встроенным” уровнем каяества. Неправильно – это когда человек забивает на свой высокоприоритетный таск и вместо него начинает рыться по коду, применяя все что может из пункта меню “Рефакторинг” в его eClipse, например – исходя из его священного представления о качестве кода. В этом есть всегда типичный паттерн – человек тихонько съезжает со своего приоритетного таска и, обычно никому этого не коммуницируя, борется за “качество”.

      Самое главное противоречие в этом то, что это – не качество, а формальное применение методов, прочитанных в последней книге. В то время как работает по-настоящему только то, что команда выработала для себя в качестве привычки. То-есть опять же, качество системы может быть только коллективным продуктом.

      Но я согласен с Ra в том, что стремление должно быть. Оно должно быть в разумных пределах, методы должны обсуждаться, быть понятными и понятыми всей командой и трейд-офф “качество-сроки” должен быть команде понятен.

    5. 2 Ra. Качество качеством, но про бизнес-то тоже забывать не надо. :) мне кажется, хороший разработчик – тот, который понимает цели проекта, в котором участвует. И тот, у которого “встроенные фичи” не заслоняют эти цели.

      Качество с самого начала – это наше все. Только проекты часто приходят уже прожившие жизнь, а то и не одну. )

    6. 2 Alex – точно, вот это я и имел в виду. :)

    7. Про переписывание кода с нуля хорошо сказал Джоэл Спольски восемь лет назад:
      http://joelonsoftware.com/articles/fog0000000069.html

    8. Эта статья Джоэла у “борцов” является нелюбимой. :)

    9. В плане “причесывания” кода втихую хорошо помогают ежедневные митинги. Тогда девелопер прячет глаза и становится понятно, что что-то здесь не так ;)

    10. Я к этой проблеме отношусь так: раз в какое-то время, когда нет совсем гоящих проблем и небо не упадает на землю, я говорю: “Ок, давайте проведем рефакторинг!”. При этом я совершенно отчетливо понимаю, что:
      1. сроки ГАРАНТИРОВАННО будут провалены
      2. на НЕКОТОРОЕ ВРЕМЯ будет внесена нестабильность в продукт
      3. это нужно для поддержания в моей команде творческого начала и желания повысить качество продукта (с их точки зрения)

      Т.е. я это делаю не для продукта, а для команды. Я рассматриваю такой рефакторинг как одно из средств мотивации. Единственным условием, при котором этот подход работает, является четкое понимание пунктов 1 и 2 и РАЗУМНОСТЬ аргументов за рефакторинг.

    11. По моему адекватно, в начале разработки проекта довести до программистов “Стандарты кодирования”, которыми должен руководствоваться каждый. Иначе вон из проекта.

      Заниматься этим, когда много чего понаписано во многих смыслах опасно.

    12. Большинство людей неправильно понимают слово “рефакторинг”. Думают что это означает “переписать наизусть”. Однако правильный рефакторинг делается маленькими уверенными шажками.
      Рефакторить тоже надо уметь так, чтобы рефакторинг не приводил к нестабильности. А это пракически невозможно без хорошего покрытия кода автоматическими тестами. Разработка которых должна быть практикой, которой команда постоянно придерживается. То есть, как говорит Alex Yakima, качество должно быть “встроенным”.

      Вопрос конфликта бизнес-ценности и качества в Аджайле решается так. Есть Product Owner, который заведует требованиями и их приоритетами, и не лезет в реализацию. Ему не обязательно даже знать про “рефакторинг”, “юнит-тесты” или “континуоус интегрейшен”, которые делает команда. Команда даёт свои оценки на реализацию тех или иных фич, и отвечает за них. Вопрос “порефакторить или написать фичу” решается обычно сам собой, во внутрикомандном обсуждении. Команда стремится достичь цели итерации, выполнить то, за что взялась. Команда сама определяет балланс между внутренним техническим совершенством и количеством фич, которые у нее просят. Сама заботится о качестве. Таким образом, сказать “наш код плохой” довольно трудно – сами же делали. А если к такому решению приходят – то осознанно и все вместе.

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

    13. 2 anton_nix – втихую, да. :) Но иногда и менеджеры таки идут на поводу.

    14. 2 Alex – наверное, еще и компетенция команды все-таки на уровне? Иначе там такого натворят…

    15. Стандарты кодирования – это про кодирование. А рефакторинг – это иногда и про архитектурные изменения.

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

    16. 2 Алексей. Это разумная система, вэт саундз гут. )

    17. И ещё: рефакторинг надо делать не “из любви к искусству”, а когда текущий дизайн действительно показал себя с плохой стороны: мешает внести очередное изменение, провоцирует внесение множественных багов etc. Т.е. рефакторинг должен быть таким же шагом в направлении создания business value, как и разработка фичи. И рефакторинг, не помогающий команде в достижении ближайших бизнес-целей – отклонение такого же рода, как gold-plating, разработка фич не имеющих конкретной бизнес-ценности.

    18. Это понятно. Самый интересный момент – как это продать заказчику или продакт оунеру, когда к тебе пришла масса легаси кода. Рефакторинг – фича внутренняя, заказчику не очень видная. Однако требующая ресурсов. Очень хочется посмотреть видео Майкла Физерса на эту тему.

    19. Помоему лучший инструмент от рефакторинга – это периодический командный code review: когда команда смотрит на свой код, сама находит скопления говнокода и точечными ударами рефакторит.

    20. Командное ревью – это точно, хорошее средство. Вообще по-моему, главное в рефакторинге – это чтобы квалификация борца превышала квалификацию творца. :) Иначе борец может просто не вкурить, что тут и зачем до него написали.

    Leave a reply

    You must be logged in to post a comment.