Чтобы вести разработку быстрее, необходимо замедлиться

https://www.infoq.com/articles/slow-down-go-faster
  • Перевод


От переводчика:
Начало года — отличное время, чтобы вдумчиво оценить прошедший год. Окинуть широким взглядом происходящее и понять, как сделать 2019 год лучше, спокойнее и продуктивнее. В этом деле нам показалась полезной статья How To Slow Down to Go Faster Than Ever in Software Development, которую написал Lemi Orhan Ergin. А ее перевод мы публикуем ниже.

Основные тезисы:


  • Спешка не делает нас быстрее или эффективнее; она увеличивает стресс и лишает возможности сфокусироваться. Вместо спешки нужны творческий подход, эффективность и сфокусированность.
  • Нанимайте самых талантливых специалистов, работайте сообща, практикуйтесь и учитесь вместе. Так вы повысите профессионализм и создадите культуру мастерства в компании.
  • Наращивайте гибкость команды и эффективность процессов, составляя планы и регулярно сверяясь с ними. Находите, анализируйте и устраняйте любые источники пустых трат времени.
  • Вы не можете быть гибкими без качественной кодовой базы. Устраняйте дефекты, чаще выпускайте версии, пишите тесты до написания основного кода, проводите рефакторинг, сосредоточьтесь на простом дизайне.
  • Работающее ПО не означает качественно разработанное. Только настоящие профессионалы могут построить добротное программное обеспечение, которое позволит вам развиваться максимально быстро.

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

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

Я помню, как во время телефонного разговора с product-менеджером я сказал, что нам необходимо переписать всю систему. После 30 секунд молчания менеджер спросил: «Ты говоришь, что твоя команда разработала продукт настолько низкого качества, что теперь эта же самая команда должна переписать этот же продукт заново, но на этот раз сделать лучше. Верно? Прости, но это неприемлемо. Вы должны были писать его лучше сразу.»

Зомби-ПО нуждается в переписывании, снова и снова


В соответствии с докладом Standish Group’s Chaos Report, 94% проектов переделывались с нуля более одного раза. Это огромная цифра. Вспоминая проекты, над которыми я работал, я понимаю, что практически все они были переписаны с нуля на новых технологиях, с новыми архитектурой и дизайном. Переписывание с нуля — настолько типичное явление для нашей отрасли, что нередко компании рассматривают его как единственный способ развития и управления проектом. Сначала мы пишем, а потом переписываем и переписываем, снова и снова.

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

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

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

Производительность команды (capacity), генеральный план, оценки трудозатрат, фиксированные рабочие часы, дедлайны и скорость команды (team velocity) — все это иллюзорно. Некомпетентность реальна. Скорость поставки напрямую зависит от профессионализма людей, эффективности процессов и качества выполненной работы. Чаще всего, разработчики сами выставляют себе внутренние дедлайны, даже если в этом нет никакой необходимости.

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

Robert C. Martin отлично высказался по поводу legacy-систем в своем twitter: «Если ваше ПО становится все сложнее и сложнее разрабатывать, вы что-то делаете неправильно». Работая в спешке, мы настолько снижаем качество, что с каждым шагом работа замедляется все сильнее. Я уверен: единственный способ разрабатывать быстрее – замедлять процесс, пока мы не достигнем стабильности.

Спешка при разработке ПО — зло


В одной из серий CleanCoders Robert C. Martin сказал: «Главная ценность ПО – это способность системы приспособиться к будущим изменениям и упростить их внесение». Спешка – это зло при разработке ПО. Любая попытка поторопиться приведет к серьезному падению продуктивности, сфокусированности, эффективности людей, приспособленности к изменениям и гибкости ПО.

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

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

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

  • Люди – повышение профессионализма и мастерства,
  • Процесс – улучшение гибкости и эффективности,
  • Продукт – улучшение качества и автоматизация.

Где замедлиться, если речь идет о людях


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

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

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

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

Перестаньте работать поодиночке, работайте сообща. Не допускайте разрозненности в команде. Одиночки и разработчики-герои — признак дисфункциональности организации. Сидите рядом, вплотную. Задавайте стандарты всей командой. Работайте парами или группами; проводите review вместе. Позвольте всем участникам процесса быть ответственными за результат.

Практиковаться вместе — наиболее эффективный способ прокачать свои навыки. Взаимодействуя, мы не только вдохновляем других людей, но и учимся друг у друга. Регулярно устраивайте всей командой code retreat, coding dojo и randori. Проводите по 30 минут каждый день, просто практикуясь.

Позвольте знаниям распространяться среди людей. Учитесь вместе. Я проводил Brown Bag/Lunch&Learn сессии со всеми командами, в которых работал с 2010 года. Дважды я слышал от своих коллег: «Участие в сессиях по средам позволяет мне прокачиваться, и это очень меня мотивирует». Это наглядно отражает пользу проведения регулярных внутренних митапов.

Собирайте обратную связь и давайте ее другим. Для сбора коллективной обратной связи устройте Большую Ретроспективу. Я делаю так уже не один год. Кстати, это отличный способ погрузиться в решение проблем группой из 20 и более человек.

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

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

Вы не дети. Организация — не ваши родители. Каждый должен самостоятельно управлять своей карьерой и инвестировать в себя. Если ваш вклад подразумевает трату времени или денег, сделайте это ради себя.

Как замедлиться и улучшить процесс


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

Планы ничто, но планирование — все. Составьте план и постоянно его пересматривайте. Особенно на ранних этапах проекта, когда нужна максимальная гибкость. Ежедневной сверки с планом, например daily scrum или daily standup недостаточно. Необходимо теснее взаимодействовать внутри команды, работать парами и сверяться с планом еще чаще. Сохраняйте минимальную длину итераций вплоть до одной недели. Организуйте множество каналов обратной связи, проводя регулярные review и демо-сессии.

Определите краткосрочные и долгосрочные цели. Краткосрочные цели задают фокус для команды, долгосрочные препятствуют его потере.

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

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

Пустые траты (waste) — это все, на что вы тратите время, но что не имеет ценности для бизнеса. Находите и устраняйте пустые траты в офисе, в коде и в бизнес-процессах.

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

Вы можете обнаружить пустые траты в любой точке цикла разработки системы. Следуйте четко сформулированным критериям готовности (definition of done) и устраняйте задачи в духе «на 90% закончил, осталось еще 90%».

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

Как замедление может улучшить качество продукта


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

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

Я работал в командах, которые тратили почти все свое время на исправление ошибок и сопровождение проекта. Причина их страданий заключается в нестабильной работе на production. Чтобы продолжить разрабатывать новый функционал, одновременно исправляя ошибки, придется разделить команду на виртуальные команды. Например, в каждую итерацию мы выбираем двоих ребят, которые занимаются поддержкой и исправлением ошибок. Мы называем их Бэтменом и Робином. Независимо от того, какой функционал вы торопитесь закончить, баги исправляются без отрыва от основной разработки.

Нередко разработчики и так используют одну из практик замедления для дальнейшего ускорения — pull request-ы. Они останавливают текущую разработку, выполняют проверки и проводят code review, чтобы улучшить качество кода. Непроверенный код никогда не попадет на production.

Нашей конечной целью должен быть переход к Continuous Delivery и частые релизы. Начиная с использования веток git и заканчивая стратегиями развертывания, от способов обеспечения обратной связи к практикам автоматизированного тестирования – для всего этого необходим особый подход.

Практики, используемые вами на разных этапах цикла разработки ПО, наглядно показывают, как быстро вы ведете разработку. При работе с ветками используйте подход «commit early, commit often, perfect later, publish once». В случае работы без веток используйте Feature Toggles. Это позволит устранить пустые траты времени.

Я использую TDD уже не один год. Нередко люди жалуются мне, что TDD негативно влияет на скорость разработки. Joe Rainsberger поделился своими мыслями о TDD в twitter: «Переживаете, что TDD замедлит ваших программистов? Не надо. Вероятно, им и нужно замедлиться».

TDD – это больше рефакторинг, чем тестирование; больше размышления, чем кодинг; больше простота, чем элегантность. Вот почему TDD ведет к более высокому качеству. При использовании TDD у вас будет лишь минимально достаточное количество тестов и простой дизайн.

Вы когда-нибудь добивались стопроцентного покрытия кода тестами? Я достиг его в трехмесячном проекте, покрыл тестами каждую строчку production-кода. В тот момент я ощущал себя героем со сверхспособностями. Но когда мы развернули систему на preproduction для проведения приемочного тестирования, то заметили, что четыре функции не работают. Я написал интеграционные и функциональные тесты, чтобы найти и исправить ошибки. В тот момент я понял, что unit-тесты не гарантируют хороший дизайн и работающий функционал. Перестаньте считать процент покрытия кода тестами. Эта метрика ничего не показывает.

Исправляйте ошибки сразу, если для этого понадобится 30 минут или меньше. Дополнительно используйте 20% времени для устранения технического долга.

Как правило, мы пишем код без намерения менять его в дальнейшем. При проектировании системы мы аналогичным образом выбираем технологии и инструменты, планируя не менять их в будущем. Но мы ошибаемся. Рефакторинг должен быть возможен на любой стадии проекта. Как говорит Kent Beck, мы должны сделать легкие изменения, чтобы дальнейшие изменения были легкими. Чтобы это стало возможным, мы храним код всех наших микросервисов в моно-репозитории. Это позволяет сделать рефакторинг легким, и это действительно необходимо.

Любое решение при проектировании ошибочно, если оно принято раньше, чем стало необходимым. Следует ждать последнего приемлемого момента для принятия решения. Мы используем архитектуру «Порты и адаптеры», чтобы достичь слабой связаности (low coupling) и высокого зацепления (high cohesion) на уровне дизайна всей системы. Благодаря этому, мы получаем отлично спроектированные монолиты.

Монолит – это не зло, зло – это плохой дизайн. Мы всегда начинаем с разработки монолита, а благодаря архитектуре “порты и адаптеры” мы извлекаем части функциональности в микросервисы. Как сказал Martin Fowler в своей статье Monolith First: «Начинать сразу с микросервисной архитектуры рискованно, лучше начните с монолита. Разделяйте на микросервисы, только когда и если это необходимо».

Замедление для ускорения как подход к жизни


Andreas Möller поделился своими ощущениями о разработке ПО в твите: «Я не хочу писать код, который просто работает. Я хочу писать код, который будет чистым, сопровождаемым, легким для понимания и хорошо протестированным».

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

Мы должны помнить следующее:

  • Работающая система не обязательно хорошо написана
  • Только настоящие профессионалы могут создать хорошо проработанную систему
  • Только хорошо проработанная система позволит вам выпускать новый функционал максимально быстро

Об авторе


Lemi Orhan Ergin — мастер разработки ПО, который стремится поднять уровень мастерства в своей отрасли и делиться своим опытом с сообществом. Соучредитель Craftbase и основатель Turkish Software Craftsmanship Community. Занимается разработкой ПО с 2001 года. Активно практикует и занимается наставничеством в таких областях как Scrum, экстремальное программирование, методологии разработки и web-технологии.
True Engineering
112,00
Специалисты по цифровой трансформации бизнеса
Поделиться публикацией

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

    0
    high cohesion и low coupling не совсем корректно переведены…
      0
      А какой перевод вам кажется корректным? Искал принятые в сообществе переводы — однозначного мнения так и не обнаружил.
        0
        обычно используется высокое зацепление и малая связанность — мне кажется это достаотчно распространненные термины
          0
          Поправил, спасибо за внимательность.
      +1
      Скорость и постоянное переписывание кода — это хорошо а не плохо. И это никак не отменяет творческого подхода и сосредоточенности. Я ни разу не встречал инженеров, которые были бы способны продумать систему полностью с нуля, описать ее тестами и реализовать за одну итерацию. Если вы думаете, что вы — именно такой — вы себя обманываете. Мы работаем в слишком сложных условиях, чтобы это было возможно в принципе. В реальном мире, нас поджидают сюрпризы со всех сторон: со стороны бизнеса, технологий, отношений в команде и так далее. Лучше выстраивать процесс и архитектуру таким образом, чтобы скорость и перманентный рефакторинг не были проблемой вообще. Это возможно, и в этом, на мой взгляд, и есть высшее мастерство разработчика.
        0

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

          0
          Полагаю что некоторые продукты со временем все же окажутся практически переписанными с нуля путем переписывания компонентов продукта, поскольку меняются масштабы их использования, требования к безопасности. Это тоже плохо?
            +1

            Когда переписывание происходит в рамках бизнес-задач как часть процесса, это одно.


            Когда product-owner приходит к бизнесу и говорит "мы не можем разрабатывать пока всё не перепишем с нуля" — это немного другой разговор. Насколько я понял, имелся в виду второй вариант

            +1
            Нет ничего плохого в переписывании с нуля, если вы четко знаете чего хотите этим добиться. В текущий момент, вы всегда можете опереться на полученный опыт работы с системой, которого у вас еще не было в предыдущей итерации. И этот опыт, порой, на многое позволяет взглянуть сильно по новому. Игнорировать это новое и пытаться лечить проблемы заплатками, будучи свято уверенными в непогрешимости изначальной архитектуры — это путь в ад. Автор сам указывает на то, что мы не пишем код в его финальной версии, но, на мой взгляд, это противоречит тому, с чего статья началась. Часто быстрая проверка теорий бывыет важнее возможности без спешки реализовать качественную систему, основываясь на неверных предпосылках.
          +6
          Люди присоединяются к компаниям, в которые верят.
          Эта фраза сразу выдаёт перевод. Я бы сказал, у нас люди присоединяются к тем трём с половиной компаниям, которые обнаруживаются на hh.ru в твоём городе.
            –1
            При том, что у них всегда есть возможность присоединиться к компаниям за пределами своего города.
            +2

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

              +1

              А как фермеры и конвейеры связаны?

                0
                Это конечно немного размыто, но суть в том, что фермеры начали загибаться после промышленной революции, т.к. горожане покупали дешёвые, конвейерные, низкокачественные продукты, которые изготавливались практически не отходя от кассы. Поэтому сейчас в плей маркете 99% игр — это шаблонная ерунда, сделанная по какому-нибудь популярному фильму, с кучей доната. И эта игра просто работает, пока люди платят. Когда перестают донатить, выпускают игру по следующему фильму.
                  0
                  Наверное имелись в виду ремесленники против мануфактур.
                  До конвейеров на мой взгляд еще не доросли.
                0
                Знаю примеры, когда ненастоящие «профи» кивали на то, что для них система плохо проработана, а также, когда настоящие профи (способные эффективно и надёжно выполнить задачу в сложных условиях) в работающей, но плохо проработанной системе максимально быстро выпускали новый функционал или исправляли баги, заодно кое-что в ней проработав.
                Из-за этого становится непонятно — в чём смысл статьи, на кого она рассчитана?
                Возможно, лучше понять ответ на этот вопрос поможет мысль из неё, где учат разработчика «дисциплинированному подходу» — самому проверив фикс, спокойно отправлять исправления бага сразу на production.
                  +1
                  Не путайте виртуозов и проффесионалов. Виртуоз — это из кино, когда там какой-то псих ежесекундно рискуя, умудряется чудом в одиночку расстрелять кучу врагов и победить. ПРикольная стратегия, но работает раз из ста, потом про это кино снимают. Профессионал, это тот кто знает что для штурма укрепленного противника требуется в пять раз больше сил, чем укрепилось и артилеррийская подготовка.
                    0
                    Спасибо, но в моём комменте и в статье не mil-, а it- тема, в рамках которой мне более близка мысль, что только настоящие профессионалы могут создать достаточно проработанное качественное программное обеспечение, (что не должно было вызвать видений виртуозов и прочей чертовщины).
                      +1
                      Профессионал — это не волшебник. Профессионально отказаться выполнять задачу, если сроки или ресурсы недостаточны, потому что твоя задача — гарантировать результат. Непрофессионально взяться за задачу и просрать ее. Непрофессионально соглашаться на заниженные ресурсы и заниженное время.

                      Профессионал при анализе ситуации должен четко заявить, что в указанное время задачу выполнить не удастся, а не рвать на груди рубашку: «Все сделаем!».

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

                        С другой стороны. Реалистом (на определённом уровне управления) обещанный срок обычно умножается на 2..3, т.е. если первые сказали – сделаем за одну, но вышло за две недели, (ту же задачу, за ту же цену, с тем же качеством, что и вторые за месяц), при этом целью является — раньше конкурентов создать/предоставить продукт на рынок, то Реалисту лучше сотрудничать с первыми (разобравшись с удовлетворительной причиной их задержки), а «тормозов» (с гарантированно в два раза худшей производительностью) пожелать конкурентам.
                        Вопрос 2. Кто в Вашей иллюстрации что-нибудь не на любительском уровне понимает в целевых критериях или про риски и управление ими?
                          0
                          У меня был риск-менеджмент в универе, но я б не сказал, что нам его давали хорошо)))

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

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

                          Вы опять же судите с любительской точки зрения:«скажут неделя, сделают за две». Если ваша задача ускорить проект максимально, вы делаете премию за скорость, и штраф за просрочку. Если грубо, +1% к цене контракта за каждый досрочный день, и -1% за каждый просроченный день. Это отсечет любителей. Вы можете сделать свободный срок, что его указывали сами разработчики, но определить формулу выигрыша тендера, который будет учитывать указанный срок.

                          В США если вы все просрете к фигам, но сделаете точно по договору, учитывая штрафные санкции, то вам напишут положительное рекомендательное письмо.
                            0
                            Моя точка зрения в том, что при взаимодействии с настоящими профессионалами (если посчастливится их найти) необходимо уметь выстраивать с ними добрые и долгосрочные отношения, без крючкотворства и прочих странных вывертов в договоре.
                              0
                              Тогда у вас нет шансов поработать с профи. Профи не будет работать без договора и грамотно оформленного ТЗ.

                              Если только профи с раздвоением личности)) Он должен грамотно и ответственно кодить, но разгильдяйски и с кондачка договариваться, так что ли? Типа развратная девственница.
                                0
                                Например, на первой фазе (до договора и ТЗ), самое важное, чтобы с профи взаимодействовали адекватные, грамотные и коммуникабельные люди.
                  +7
                  Все это работает когда твоя фирма делает свой продукт. У нее есть стремление улучшать свои процессы, адаптироваться и так далее. Другой тип разработки — полный аутсорс. И для таких ребят, которые программируют на заказных проектах — это все это звучит как насмешка. Они бы и рады все это тоже делать, да кто им даст. Нужно фигачить без оглядки, потому что заказчик назначил релиз на вчера. На костылях с завязаными глазами, через поле граблей (по которому бегают еще десять подрядчиков) без карты, к финишному флажку, после которого не конец, а следующий раунд.
                    0
                    Я помню, как во время телефонного разговора с product-менеджером я сказал, что нам необходимо переписать всю систему. После 30 секунд молчания менеджер спросил: «Ты говоришь, что твоя команда разработала продукт настолько низкого качества, что теперь эта же самая команда должна переписать этот же продукт заново, но на этот раз сделать лучше. Верно? Прости, но это неприемлемо. Вы должны были писать его лучше сразу.»


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

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

                          Кстати, несложно догадаться, что в моём замечании речь идёт о руководящих позициях, типа +1 относительно сеньора, на которые следует не назначать некомпетентных специалистов или, контролируя, своевременно выявлять таковых и снимать с проекта.
                            +1
                            Если у вас есть другие предположения, почему сеньор сообщает эти новости левому продакт-менеджеру, а тот еще и отчитывает сеньора, который ему не подчиняется, я готов рассмотреть их правдоподобность.
                              0
                              Извините, я не могу говорить серьёзно, возможно, ситуация c телефонным разговором выглядела примерно так:
                              Product-менеджер, не обладающий ни авторитетом, ни влиянием на сеньора, делится своими новыми планами, как должен выглядеть выпускаемый продукт через Х лет.
                              Сеньор, в ответ, говорит о низком качестве текущего продукта, с точки зрения его модифицируемости в рамках этих планов, и будущей необходимости переписать этот же продукт заново.
                              Product-менеджер гневно высказывает сеньору, что это безобразие какое-то, надо было сразу писать его лучше.
                              Кладётся трубка.
                              Сеньора одолевают сомнения в адекватности собеседника.
                                –2
                                Извините, я не могу говорить серьёзно

                                С этого следовало начать.
                                  0
                                  В готовности рассмотрения вариаций телефонного трёпа смысла ноль, предлагаю вниманию серьёзный вопрос — риск замедлением ухудшить качество продукта, если, занявшись типа чем-то оптимизирующим (например, неуместной автоматизацией), не получили ожидаемого эффекта и потеряли впустую время и деньги. А срок выпуска продукта не передвинуть и финансирование уже выделено/ограничено. Условия, при которых одни специалисты загоняют себя или создают цейтнот и стрессы другим (следующим по технологической цепочке), возникают из-за непродуманных и безответственных решений «креативного» руководства, согласовывающего сеньору «благое» замедление.
                        0
                        По моей практике, увидеть целостную картину, не запрограммировав частные случаи и не проведя после этого анализа — зачастую невозможно. К тому же на месте менеджера, который мудак зачастую находится клиент, который, как известно, всегда прав, к тому же заплатил деньги.
                        Поэтому да — хорошо, когда есть возможность остановиться, проанализировать, переделать, и только потом двигаться дальше.
                        0
                        «Позабыв покой и лень,
                        Делай деньги, делай деньги,
                        А остальное всё — дребедень!» (с)

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

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

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