Гибкие методологии: взгляд со стороны бизнеса (часть 1)

Подавляющее большинство из нас прекрасно знакомы с гибкими методологиями разработки, читали agile-манифест, работали по scrum или kanban. Некоторые — успешно внедряют в своих отделах те или иные agile-практики, иные — пропагандируют отказ от них в пользу других методологий. В общем, тема не нова, хорошо знакома и изрядно заезжена.


Однако большинство публикаций посвящены лишь внешней стороне вопроса, где даются именно те ответы, которые психологически мотивируют исполнителей принять «agile», но очень мало предоставляется информации о том, зачем же это нужно бизнесу (или же, что хуже, пользу для бизнеса пытаются вывести из предназначенных для сотрудников лозунгов).


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


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


  1. Люди и взаимодействие важнее процессов и инструментов
  2. Работа короткими итерациями
  3. Готовность к изменениям важнее следования первоначальному плану

Люди и взаимодействие важнее процессов и инструментов


Первый постулат agile-манифеста, трактуемый совершенно противоположно исполнителями и бизнесом. И не просто так он вынесен именно на лидирующую, открывающую сам манифест позицию — именно за ним стоит одна из самых разрушительных для бизнеса «болей».


Проблема


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


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


Решение


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


Достигнутая цель


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


Мотивация разработчиков


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


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


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


Внутренние конференции могут позволить себе только крупные игроки, но они дают разработчикам возможность блеснуть профессионализмом перед своими коллегами и почувствовать себя оцененными по достоинству. Для компаний с небольшим количеством разработчиков в 10-20 человек отлично подходит организация внутренних «курсов» по смежным дисциплинам, на которых, например, фронтенд-разработчик может прочитать несколько лекций по vue.js для своих коллег, программирующих бекенд на .net core. «Преподаватель» в этом случае сможет удовлетворить свою потребность в признании, «студенты» получают возможность профессионально расти и пробовать новое, а бизнес вдобавок к возросшей вовлеченности сотрудников совершенно бесплатно получает более квалифицированные кадры, знакомые притом с не затрагивавшими их раньше аспектами работы.


Ведение внутренней базы знаний — сложная и требующая времени задача, а полнота информации зависит исключительно от вовлеченности участвующих в ее дополнении. Актуальная база знаний не может быть заполнена в директивном порядке, и самый действенный вариант — сделать актуализацию данных почетной. Для этого подойдет использование «внутренней валюты» (условных звездочек-наград, которые можно на что-то обменять), публичная похвала («Вася 2 месяца назад по твоему вопросу все очень здорово описал, посмотри в wiki»). Основное — участвующие в ведении базы знаний сотрудники должны быть убеждены, что их ценность для компании от этого растет.


Критика


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


Защита


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


Работа короткими итерациями


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


Проблема


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


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


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


Решение


Раздробить работу на короткие промежутки, где в конце каждого этапа сотрудники обязаны предъявить минимальный жизнеспособный продукт, пусть с небольшим, но доказанно работающим готовым функционалом. Это должна быть именно работающая программа (сервис, приложение, сайт), готовая к тиражированию. «Сферические алгоритмы в вакууме» и приложения, запускающиеся только на машине разработчика, не допускаются, приравниваясь к невыполненной работе. На каждой итерации требуется именно готовый продукт.


Достигнутая цель


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


Мотивация разработчиков


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


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


Критика


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


Защита


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


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


Один из постулатов agile-манифеста, неразрывно связанный с упомянутой выше работой короткими итерациями.


Проблема


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


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


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


Решение


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


Достигнутая цель


Возможность быстрых и максимально «дешевых» изменений продукта и ПО.


Мотивация разработчиков


Основополагающими являются два принципа.


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


Во-вторых, у сотрудников должна быть реализована потребность в безопасности. Любые новые (часто противоречивые) требования заставляют многих испытывать стресс, чувствовать личную ответственность за то, что реализованные фрагменты системы оказались не нужны, или же чувство вины за якобы плохо сделанную работу. Это крайне опасно для микроклимата в коллективе и ведет к снижению производительности труда, мотивации, а иногда даже способно развалить команду. Чтобы ни в коем случае не допустить падения «боевого духа», крайне важно каждое изменение позиционировать как новый вызов и возможность.


Критика


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


Защита


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



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

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

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

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

    +2
    Все «проблемы» скрама и аджайла — вы просто не сечете фишку.

    Все же просто очень. Когда вы отказываетесь от иллюзии того, что вы можете чем-то «управлять», вы встаете перед вопросом «но если управление не возможно, как же мне тогда завершить мой проект?».

    Скрам — не какая-та шаманистическая практика (как кое-кто тут уверен), а, наоборот, ответ на вопрос что вы будете делать, когда примете на себя обязательство абсолютной честности по отношению к себе и к окружающим?
      +1

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

        0
        Смотрите. Когда речь идет о взаимодействии между людьми, есть в общем-то всего два варианта: тирания и сделка. Скрам — сделка.
        Если вы пытаетесь выдать тиранию за сделку, у вас проблема. Эта проблема больно стукнет и вас и тех, кого вы пытались обмануть.
          0
          Мне крайне лестны Ваши слова о том, будто бы я пытаюсь кого-либо обмануть или выдать тиранию за выгодную сделку, ведь это означает лишь то, что я действительно сумел показать проблему с другой стороны, а в этом и была моя цель. Но я не выступаю в роли «адвоката дьявола».
            0
            Ну, тогда я не совсем понимаю, для чего нужна ваша статья. Все взрослые люди и так умеют вступать в отношения и поддерживать их. Кого и чему вы хотите научить?
        +2

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

          –2
          Нет. Это, имеется в виду, что как раз «руководство» трезвеет и только после этого оно готово к скрам-команде. Иначе проблемы будут.
            +1
            В жизни бывают разные ситуации, однако отношение к руководству (Вы даже взяли это слово в кавычки) как к врагу, которому нужно обязательно «трезветь» лично я нахожу не вполне уместным. Я не вижу необходимости без крайней нужды ни возводить, ни рушить баррикады, основываясь лишь на делении по принципу «свой-чужой».
              –2
              Ну, вот смотрите. Вы пишете «Во-первых, необходимо внедрить мысль о том, что гибкость — в самой основе природы.». Вы не можете внедрить мысль.
              Дальше, «крайне важно каждое изменение позиционировать как новый вызов и возможность.». Опять же. Позиционирование — это какая-то уловка. Каждое конкретное изменение может быть вызовом или возможностью по факту. Вы не можете изменить оценку изменения, просто сказав другие слова. Нет никакой нужды добавлять про позиционирование. Все, что вы говорите или правда и не нуждается в каких-то уловках, или нет. А у вас я вижу сборник уловок. Сама необходимость уловок говорит о том, что что-то идет не так.
        0

        Сложилось двоякое впечатление от статьи
        Кажется что вы используете Agile только для того что дать ощущение ответственности, как пример:


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

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

        и т.д.
        Если подходить к сотрудникам с такой позиции то в какой-то момент они за эту двойственности будут ненавидеть Agile и все что с ним связано

          +1
          Спасибо за Ваш отзыв. Взращивание ответственности сотрудников — тот аспект, которым нельзя пренебрегать. Разработчик (а мы говорим именно о них) конечно же должен понимать свою значимость в рамках проекта и компании, от этого будут расти его удовлетворенность работой и продуктивность. Я не говорю, что эта цель — единственная или основная, но с точки зрения бизнеса ее достижение немаловажно.
          Что касается ненависти или любви, то этот вопрос исключительно индивидуален и зависит не от самого факта использования тех или иных инструментов, а от конкретной ситуации на конкретных местах. Я намеренно не даю оценок, а предлагаю как критику, так и слова защиты в пользу каждого пункта.
            0

            Здесь вопрос не в ненависти а в том как это выглядит для двух сторон 
            Как пример: 
            руководство заинтересованное и дающее возможности проявить себя на местах (взяв при этом ответственность за результат и качество) — это прекрасно
            Но чаще руководители стараются постоянно контролировать PO (не допускал ошибок) на этом этапе Agile "контракт" перестает работать

              +1
              Для бизнеса на первом месте всегда будет стоять цель извлечения прибыли. Какими пользоваться для этого инструментами управления — зависит и от сферы деятельности, и от личности собственников/инвесторов, и от большого количества других факторов. И какие бы средства ни были задействованы, цель одна — получение M рублей с N вложенных. Однако, опытный руководитель понимает, что личная заинтересованность и разумная инициатива на местах позволит зарабатывать больше, а тратить — меньше (за счет отсутствия «текучки» — найм квалифицированного сотрудника обходится в кругленькую сумму, повышения продуктивности сотрудников, их большей лояльности и т.д.). И это будет ситуация win-win, при которой все будут только в плюсе.
              Если же говорить об описанной Вами ситуации, когда инструмент используется не совсем верно, то проблема, говоря иносказательно, не в молотке, а в том, кто его держит, начинает заниматься микроменеджментом, вводить странные kpi, и творить прочее «зло». Но так бывает, увы.
          0

          Так же хотелось отметить пункт "Работа короткими итерациями":


          • Длинна спринта в том же Scrum не регламентирована и подбирается под продукт и команду
          • Overhead возникает на этапах тестирования ( ручного ) передачи в различные контура, настройки environment и тд...
          • Автоматизация цикла SDLC в большей степени снимает лишний overhead (время на него конечно прийдется потратить) и помогает двигаться без замедления
            –1
            Давайте переразберу некоторые ваши пункты:

            Люди и взаимодействие важнее процессов и инструментов
            Это очень интересная проблема, которая выходит за рамки, собственно, разработки. Дело в том, что традиционно программирование было (и во много остается) вотчиной людей с особым складом ума, шизоидным. Они всем хороши, но, увы, не понимают социальных сигналов. В сущности, шизоиды идут по жизни, просто приучая себя делать одну и ту же вещь много раз, и это они называют «процессом».
            Увы, но большинство людей не являются носителем такого радикала и они просто не выживают в шизоидной среде. Они просто не могут следовать «процессам». То, как простые люди ведут дела — бьют других людей по голове (морально) и они называют это «взаимодействием» и «коммуникацией».
            В итоге, возникает конфликт ценностей «процесс»/«коммуникация», который авторы скрама и agile-манифеста решают в пользу «коммуникации». Все остальное — в сущности, просто поддерживающие процедуры.

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

            И вот тут у вас должен прозвенеть звоночек: «если я не перегружаю отдел разработки задачами, зачем мне нужны итерации и вообще аджайл?». И вот тут то как раз и вступает в дело «трезвость руководителя», о которой я писал выше. Руководитель должен осознать неуправляемость и поменять свою стратегию поведения с «контроля исполнения» на «пойду, выясню, как обстоят дела на самом деле». Узнаете много нового. Появится что разрабатывать. И сама идея о том, чтобы разрабатывать что-то по полгода этапами начнет приводить вас в ужас.
              +1
              Как я и писал, каждая из практик призвана решить целый спектр проблем, а не одну конкретную задачу, в этом Вы, безусловно, правы и я благодарю Вас за то, что упомянули и альтернативные сложности. Но!
              От стереотипов
              традиционно программирование было (и во много остается) вотчиной людей с особым складом ума, шизоидным

              давно следует отказаться наравне с гендерными предрассудками, как от не соответствующих действительности и оскорбительных. В IT работают разные люди: интроверты и экстраверты, носители абсолютно разных поведенческих и психологических паттернов, представители разных социальных групп, командные игроки и индивидуалисты-одиночки, люди с разными, лежащими не только в профессиональной сфере, интересами.
                0
                Я только за. Но я структурирую информацию об окружающем мире так, как структурирую, и если вы назовете лучшее слово, я буду его использовать.
                  0
                  Предлагаю сойтись на том, что мы просто по-разному смотрим на вопрос :) Я со своей стороны считаю, что разработчики НЕ являются носителями «шизоидного» склада мышления, а любая профессиональная деформация, если она и присутствует, не всегда затрагивает аспект коммуникации.
                    0
                    Если мы по-разному смотрим на вопрос, то мы должны прийти к одинаковым по-сути выводам, но разными словами, а пока что я вижу, что выводы диаметрально противоположные.

                    Ну, хорошо, допустим, не шизоидного. А какого тогда?

                    Давайте я уточню пару моментов: во-первых, я ссылаюсь на временной промежуток до начала 2000-х. А во-вторых, я не имею в виду буквально что «все программисты были шизоидами», а что шизоидный радикал в тот период имел преимущество и лидеры того времени организовывали разработку удобным для себя способом.
                    Также, я абсолютно не имею в виду профессиональную деформацию. Речь идет о способе мышления. Шизоиды принципиально отличаются от обычных людей способом мышления.
                      0

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

                        0
                        А почему Вы считаете, что мы должны прийти к одинаковым выводам, если я с Вами не согласен, о чем и написал?

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

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

              Собственно есть одна простая хотелка — разработчики хотят творить. Да, они хотят. А бизнес считает, что это слив денег в пустоту. Ну вот они и дерутся. И разумеется, если речь идёт о драке, то все будут обманывать всех. Бизнес будет придумывать «идеи» и «технологии», а разработчики будут всячески филонить и уворачиваться. То есть конфета получается с запахом гари, как минимум. А если небольшая гарь перешла в пожар, то запах уже может быть даже из штанов.

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

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

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

              Хотя если ещё шире взглянуть — капитализм тренирует жадность. Ну и от этого при капитализме нет друзей среди «персонала» или «начальства», в зависимости от стороны, на которой находится читатель. Поэтому аджал и конфеты с запахом дерьма. Только суровые сделки и никаких вам win-win. За потогонный аджайл платите больше. Кризис откатит — значит через годик-другой придётся поднатужиться и выйти на докризисный уровень. Не смогли? Тогда мы идём к тем, кто смог. И разумеется, филонить будем и там. Хотя вам скажем, что мы вас, ну разумеется, очень любим и ценим, только деньги не забывайте переводить.
                0
                Вы правы в том, что никакой ситуации win-win не может быть, если сотрудник относится к работодателю как к эксплуататору. Контакт в этом случае наладить действительно не представляется возможным. Любое продвижение к взаимовыгодному сотрудничеству должно быть двусторонним. Если уж и пришлось работать с такими токсичными и недальновидными разработчиками, как Вы описали, то расставаться с ними нужно немедленно и без сожалений, ведь они одновременно и тормозят самых талантливых, и готовы затянуть в своих липких сетях на дно весь коллектив.
                  –1
                  Ну правильно — война, только увольнять и ни разу не стесняться. Вы конечно же во всём правы.

                  А разработчики, особенно прочитав ваш комментарий, намотают на ус — война должна быть тайной. И очень холодной. Иначе сразу уволят.
                    0

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

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

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