Комментарии 25
Все «проблемы» скрама и аджайла — вы просто не сечете фишку.
Все же просто очень. Когда вы отказываетесь от иллюзии того, что вы можете чем-то «управлять», вы встаете перед вопросом «но если управление не возможно, как же мне тогда завершить мой проект?».
Скрам — не какая-та шаманистическая практика (как кое-кто тут уверен), а, наоборот, ответ на вопрос что вы будете делать, когда примете на себя обязательство абсолютной честности по отношению к себе и к окружающим?
Все же просто очень. Когда вы отказываетесь от иллюзии того, что вы можете чем-то «управлять», вы встаете перед вопросом «но если управление не возможно, как же мне тогда завершить мой проект?».
Скрам — не какая-та шаманистическая практика (как кое-кто тут уверен), а, наоборот, ответ на вопрос что вы будете делать, когда примете на себя обязательство абсолютной честности по отношению к себе и к окружающим?
Благодарю Вас за отзыв. Вопросы "абсолютной честности" и мнимой "горизонтальности" управления я хотел бы как раз поднять во второй статье цикла — насколько они необходимы, действительно ли честность двусторонняя, а горизонтальность — реальная, и какие проблемы они призваны решить. Никакого шаманизма, все практики — от наличия необходимости решать реальные "боли".
Смотрите. Когда речь идет о взаимодействии между людьми, есть в общем-то всего два варианта: тирания и сделка. Скрам — сделка.
Если вы пытаетесь выдать тиранию за сделку, у вас проблема. Эта проблема больно стукнет и вас и тех, кого вы пытались обмануть.
Если вы пытаетесь выдать тиранию за сделку, у вас проблема. Эта проблема больно стукнет и вас и тех, кого вы пытались обмануть.
Мне крайне лестны Ваши слова о том, будто бы я пытаюсь кого-либо обмануть или выдать тиранию за выгодную сделку, ведь это означает лишь то, что я действительно сумел показать проблему с другой стороны, а в этом и была моя цель. Но я не выступаю в роли «адвоката дьявола».
Ну, тогда я не совсем понимаю, для чего нужна ваша статья. Все взрослые люди и так умеют вступать в отношения и поддерживать их. Кого и чему вы хотите научить?
И, простите за второй комментарий подряд, добавлю: успешное управление — и есть то, при котором сотрудники верят, что решения, нужные руководству, они принимают сами, так как "управление невозможно". Это прекрасно и для сотрудников, и для бизнеса, и быть таким руководителем — высший пилотаж. На что, собственно, практики из гибких методологий и нацелены.
Нет. Это, имеется в виду, что как раз «руководство» трезвеет и только после этого оно готово к скрам-команде. Иначе проблемы будут.
В жизни бывают разные ситуации, однако отношение к руководству (Вы даже взяли это слово в кавычки) как к врагу, которому нужно обязательно «трезветь» лично я нахожу не вполне уместным. Я не вижу необходимости без крайней нужды ни возводить, ни рушить баррикады, основываясь лишь на делении по принципу «свой-чужой».
Ну, вот смотрите. Вы пишете «Во-первых, необходимо внедрить мысль о том, что гибкость — в самой основе природы.». Вы не можете внедрить мысль.
Дальше, «крайне важно каждое изменение позиционировать как новый вызов и возможность.». Опять же. Позиционирование — это какая-то уловка. Каждое конкретное изменение может быть вызовом или возможностью по факту. Вы не можете изменить оценку изменения, просто сказав другие слова. Нет никакой нужды добавлять про позиционирование. Все, что вы говорите или правда и не нуждается в каких-то уловках, или нет. А у вас я вижу сборник уловок. Сама необходимость уловок говорит о том, что что-то идет не так.
Дальше, «крайне важно каждое изменение позиционировать как новый вызов и возможность.». Опять же. Позиционирование — это какая-то уловка. Каждое конкретное изменение может быть вызовом или возможностью по факту. Вы не можете изменить оценку изменения, просто сказав другие слова. Нет никакой нужды добавлять про позиционирование. Все, что вы говорите или правда и не нуждается в каких-то уловках, или нет. А у вас я вижу сборник уловок. Сама необходимость уловок говорит о том, что что-то идет не так.
Сложилось двоякое впечатление от статьи
Кажется что вы используете Agile только для того что дать ощущение ответственности, как пример:
Необходимо дать людям веру, что их мнение ценят и слышат,...участвующие в ведении базы знаний сотрудники должен быть убеждены, что их ценность для компании от этого растети т.д.
Если подходить к сотрудникам с такой позиции то в какой-то момент они за эту двойственности будут ненавидеть Agile и все что с ним связано
Спасибо за Ваш отзыв. Взращивание ответственности сотрудников — тот аспект, которым нельзя пренебрегать. Разработчик (а мы говорим именно о них) конечно же должен понимать свою значимость в рамках проекта и компании, от этого будут расти его удовлетворенность работой и продуктивность. Я не говорю, что эта цель — единственная или основная, но с точки зрения бизнеса ее достижение немаловажно.
Что касается ненависти или любви, то этот вопрос исключительно индивидуален и зависит не от самого факта использования тех или иных инструментов, а от конкретной ситуации на конкретных местах. Я намеренно не даю оценок, а предлагаю как критику, так и слова защиты в пользу каждого пункта.
Что касается ненависти или любви, то этот вопрос исключительно индивидуален и зависит не от самого факта использования тех или иных инструментов, а от конкретной ситуации на конкретных местах. Я намеренно не даю оценок, а предлагаю как критику, так и слова защиты в пользу каждого пункта.
Здесь вопрос не в ненависти а в том как это выглядит для двух сторон
Как пример:
руководство заинтересованное и дающее возможности проявить себя на местах (взяв при этом ответственность за результат и качество) — это прекрасно
Но чаще руководители стараются постоянно контролировать PO (не допускал ошибок) на этом этапе Agile "контракт" перестает работать
Для бизнеса на первом месте всегда будет стоять цель извлечения прибыли. Какими пользоваться для этого инструментами управления — зависит и от сферы деятельности, и от личности собственников/инвесторов, и от большого количества других факторов. И какие бы средства ни были задействованы, цель одна — получение M рублей с N вложенных. Однако, опытный руководитель понимает, что личная заинтересованность и разумная инициатива на местах позволит зарабатывать больше, а тратить — меньше (за счет отсутствия «текучки» — найм квалифицированного сотрудника обходится в кругленькую сумму, повышения продуктивности сотрудников, их большей лояльности и т.д.). И это будет ситуация win-win, при которой все будут только в плюсе.
Если же говорить об описанной Вами ситуации, когда инструмент используется не совсем верно, то проблема, говоря иносказательно, не в молотке, а в том, кто его держит, начинает заниматься микроменеджментом, вводить странные kpi, и творить прочее «зло». Но так бывает, увы.
Если же говорить об описанной Вами ситуации, когда инструмент используется не совсем верно, то проблема, говоря иносказательно, не в молотке, а в том, кто его держит, начинает заниматься микроменеджментом, вводить странные kpi, и творить прочее «зло». Но так бывает, увы.
Так же хотелось отметить пункт "Работа короткими итерациями":
- Длинна спринта в том же Scrum не регламентирована и подбирается под продукт и команду
- Overhead возникает на этапах тестирования ( ручного ) передачи в различные контура, настройки environment и тд...
- Автоматизация цикла SDLC в большей степени снимает лишний overhead (время на него конечно прийдется потратить) и помогает двигаться без замедления
Давайте переразберу некоторые ваши пункты:
Люди и взаимодействие важнее процессов и инструментов
Это очень интересная проблема, которая выходит за рамки, собственно, разработки. Дело в том, что традиционно программирование было (и во много остается) вотчиной людей с особым складом ума, шизоидным. Они всем хороши, но, увы, не понимают социальных сигналов. В сущности, шизоиды идут по жизни, просто приучая себя делать одну и ту же вещь много раз, и это они называют «процессом».
Увы, но большинство людей не являются носителем такого радикала и они просто не выживают в шизоидной среде. Они просто не могут следовать «процессам». То, как простые люди ведут дела — бьют других людей по голове (морально) и они называют это «взаимодействием» и «коммуникацией».
В итоге, возникает конфликт ценностей «процесс»/«коммуникация», который авторы скрама и agile-манифеста решают в пользу «коммуникации». Все остальное — в сущности, просто поддерживающие процедуры.
Работа короткими итерациями
Работа короткими итерациями нужна не для того, чтобы бизнес мог контролировать работу. Он это всю дорогу мог и это вообще не проблема никакая.
Настоящая проблема в том, что бизнес постоянно получает новые данные от рынка и перегружает отдел разработки. Они не понимают за что взяться и в итоге вообще ничего не делают.
Соглашение, которое реализуется с помощью коротких итераций: «мы готовы к переменам, но не так часто».
И вот тут у вас должен прозвенеть звоночек: «если я не перегружаю отдел разработки задачами, зачем мне нужны итерации и вообще аджайл?». И вот тут то как раз и вступает в дело «трезвость руководителя», о которой я писал выше. Руководитель должен осознать неуправляемость и поменять свою стратегию поведения с «контроля исполнения» на «пойду, выясню, как обстоят дела на самом деле». Узнаете много нового. Появится что разрабатывать. И сама идея о том, чтобы разрабатывать что-то по полгода этапами начнет приводить вас в ужас.
Люди и взаимодействие важнее процессов и инструментов
Это очень интересная проблема, которая выходит за рамки, собственно, разработки. Дело в том, что традиционно программирование было (и во много остается) вотчиной людей с особым складом ума, шизоидным. Они всем хороши, но, увы, не понимают социальных сигналов. В сущности, шизоиды идут по жизни, просто приучая себя делать одну и ту же вещь много раз, и это они называют «процессом».
Увы, но большинство людей не являются носителем такого радикала и они просто не выживают в шизоидной среде. Они просто не могут следовать «процессам». То, как простые люди ведут дела — бьют других людей по голове (морально) и они называют это «взаимодействием» и «коммуникацией».
В итоге, возникает конфликт ценностей «процесс»/«коммуникация», который авторы скрама и agile-манифеста решают в пользу «коммуникации». Все остальное — в сущности, просто поддерживающие процедуры.
Работа короткими итерациями
Работа короткими итерациями нужна не для того, чтобы бизнес мог контролировать работу. Он это всю дорогу мог и это вообще не проблема никакая.
Настоящая проблема в том, что бизнес постоянно получает новые данные от рынка и перегружает отдел разработки. Они не понимают за что взяться и в итоге вообще ничего не делают.
Соглашение, которое реализуется с помощью коротких итераций: «мы готовы к переменам, но не так часто».
И вот тут у вас должен прозвенеть звоночек: «если я не перегружаю отдел разработки задачами, зачем мне нужны итерации и вообще аджайл?». И вот тут то как раз и вступает в дело «трезвость руководителя», о которой я писал выше. Руководитель должен осознать неуправляемость и поменять свою стратегию поведения с «контроля исполнения» на «пойду, выясню, как обстоят дела на самом деле». Узнаете много нового. Появится что разрабатывать. И сама идея о том, чтобы разрабатывать что-то по полгода этапами начнет приводить вас в ужас.
Как я и писал, каждая из практик призвана решить целый спектр проблем, а не одну конкретную задачу, в этом Вы, безусловно, правы и я благодарю Вас за то, что упомянули и альтернативные сложности. Но!
От стереотипов
давно следует отказаться наравне с гендерными предрассудками, как от не соответствующих действительности и оскорбительных. В IT работают разные люди: интроверты и экстраверты, носители абсолютно разных поведенческих и психологических паттернов, представители разных социальных групп, командные игроки и индивидуалисты-одиночки, люди с разными, лежащими не только в профессиональной сфере, интересами.
От стереотипов
традиционно программирование было (и во много остается) вотчиной людей с особым складом ума, шизоидным
давно следует отказаться наравне с гендерными предрассудками, как от не соответствующих действительности и оскорбительных. В IT работают разные люди: интроверты и экстраверты, носители абсолютно разных поведенческих и психологических паттернов, представители разных социальных групп, командные игроки и индивидуалисты-одиночки, люди с разными, лежащими не только в профессиональной сфере, интересами.
Я только за. Но я структурирую информацию об окружающем мире так, как структурирую, и если вы назовете лучшее слово, я буду его использовать.
Предлагаю сойтись на том, что мы просто по-разному смотрим на вопрос :) Я со своей стороны считаю, что разработчики НЕ являются носителями «шизоидного» склада мышления, а любая профессиональная деформация, если она и присутствует, не всегда затрагивает аспект коммуникации.
Если мы по-разному смотрим на вопрос, то мы должны прийти к одинаковым по-сути выводам, но разными словами, а пока что я вижу, что выводы диаметрально противоположные.
Ну, хорошо, допустим, не шизоидного. А какого тогда?
Давайте я уточню пару моментов: во-первых, я ссылаюсь на временной промежуток до начала 2000-х. А во-вторых, я не имею в виду буквально что «все программисты были шизоидами», а что шизоидный радикал в тот период имел преимущество и лидеры того времени организовывали разработку удобным для себя способом.
Также, я абсолютно не имею в виду профессиональную деформацию. Речь идет о способе мышления. Шизоиды принципиально отличаются от обычных людей способом мышления.
Ну, хорошо, допустим, не шизоидного. А какого тогда?
Давайте я уточню пару моментов: во-первых, я ссылаюсь на временной промежуток до начала 2000-х. А во-вторых, я не имею в виду буквально что «все программисты были шизоидами», а что шизоидный радикал в тот период имел преимущество и лидеры того времени организовывали разработку удобным для себя способом.
Также, я абсолютно не имею в виду профессиональную деформацию. Речь идет о способе мышления. Шизоиды принципиально отличаются от обычных людей способом мышления.
А почему Вы считаете, что мы должны прийти к одинаковым выводам, если я с Вами не согласен, о чем и написал? В продолжении дискуссии на тему психотипа разработчиков смысла не вижу.
А почему Вы считаете, что мы должны прийти к одинаковым выводам, если я с Вами не согласен, о чем и написал?
Потому что реальность одна и мы в ней живем. Если выводы разные, значит кто-то чего-то не понимает. И мне интересно, не я ли это.
Скрамы с аджайлами разработчики не любят. Бизнес же считает, что если он сократит итерации, то в итоге получит дешёвую конфету. Ну и убеждает себя, например аргументами из статьи, что конфета будет просто мега-вкусная. Но конфета получается хоть и дешёвая, но из плохо пахнущего материала.
Для понимания проблемы нужно выходить за рамки бизнеса. И разработчикам тоже нужно отходить от своих стереотипов.
Собственно есть одна простая хотелка — разработчики хотят творить. Да, они хотят. А бизнес считает, что это слив денег в пустоту. Ну вот они и дерутся. И разумеется, если речь идёт о драке, то все будут обманывать всех. Бизнес будет придумывать «идеи» и «технологии», а разработчики будут всячески филонить и уворачиваться. То есть конфета получается с запахом гари, как минимум. А если небольшая гарь перешла в пожар, то запах уже может быть даже из штанов.
Синергия получится если дать разработчикам творить на благо бизнеса. Как это сделать? Ну вообще просто — имея много денег можно всё. Только бизнесы обычно жадные, ну или маленькие, а потому выделять что-то на творчество не хотят. И нежелание обосновывают просто — а как понять, что за наши деньги творят для нас? Ну правильно, если нет понимания происходящего, то никак не понять, учитывая войну с разработчиками.
Поэтому разработчики должны стать друзьями, а не врагами. И кто же первый должен здесь сделать шаг навстречу? Неужели опять рядовой разработчик должен пробиваться на приём к самому главному боссу, что бы тот опять сказал старый довод — ты меня не убедил.
В общем — не умеете с людьми по хорошему — никакие аджайлы вам не помогут. И я подозреваю, что, особенно большие конторы, никогда уметь не будут. Хотя деньги выделять на «взаимодействие с персоналом» возможно будут. Но это лишь видимость решения проблемы.
Хотя если ещё шире взглянуть — капитализм тренирует жадность. Ну и от этого при капитализме нет друзей среди «персонала» или «начальства», в зависимости от стороны, на которой находится читатель. Поэтому аджал и конфеты с запахом дерьма. Только суровые сделки и никаких вам win-win. За потогонный аджайл платите больше. Кризис откатит — значит через годик-другой придётся поднатужиться и выйти на докризисный уровень. Не смогли? Тогда мы идём к тем, кто смог. И разумеется, филонить будем и там. Хотя вам скажем, что мы вас, ну разумеется, очень любим и ценим, только деньги не забывайте переводить.
Для понимания проблемы нужно выходить за рамки бизнеса. И разработчикам тоже нужно отходить от своих стереотипов.
Собственно есть одна простая хотелка — разработчики хотят творить. Да, они хотят. А бизнес считает, что это слив денег в пустоту. Ну вот они и дерутся. И разумеется, если речь идёт о драке, то все будут обманывать всех. Бизнес будет придумывать «идеи» и «технологии», а разработчики будут всячески филонить и уворачиваться. То есть конфета получается с запахом гари, как минимум. А если небольшая гарь перешла в пожар, то запах уже может быть даже из штанов.
Синергия получится если дать разработчикам творить на благо бизнеса. Как это сделать? Ну вообще просто — имея много денег можно всё. Только бизнесы обычно жадные, ну или маленькие, а потому выделять что-то на творчество не хотят. И нежелание обосновывают просто — а как понять, что за наши деньги творят для нас? Ну правильно, если нет понимания происходящего, то никак не понять, учитывая войну с разработчиками.
Поэтому разработчики должны стать друзьями, а не врагами. И кто же первый должен здесь сделать шаг навстречу? Неужели опять рядовой разработчик должен пробиваться на приём к самому главному боссу, что бы тот опять сказал старый довод — ты меня не убедил.
В общем — не умеете с людьми по хорошему — никакие аджайлы вам не помогут. И я подозреваю, что, особенно большие конторы, никогда уметь не будут. Хотя деньги выделять на «взаимодействие с персоналом» возможно будут. Но это лишь видимость решения проблемы.
Хотя если ещё шире взглянуть — капитализм тренирует жадность. Ну и от этого при капитализме нет друзей среди «персонала» или «начальства», в зависимости от стороны, на которой находится читатель. Поэтому аджал и конфеты с запахом дерьма. Только суровые сделки и никаких вам win-win. За потогонный аджайл платите больше. Кризис откатит — значит через годик-другой придётся поднатужиться и выйти на докризисный уровень. Не смогли? Тогда мы идём к тем, кто смог. И разумеется, филонить будем и там. Хотя вам скажем, что мы вас, ну разумеется, очень любим и ценим, только деньги не забывайте переводить.
Вы правы в том, что никакой ситуации win-win не может быть, если сотрудник относится к работодателю как к эксплуататору. Контакт в этом случае наладить действительно не представляется возможным. Любое продвижение к взаимовыгодному сотрудничеству должно быть двусторонним. Если уж и пришлось работать с такими токсичными и недальновидными разработчиками, как Вы описали, то расставаться с ними нужно немедленно и без сожалений, ведь они одновременно и тормозят самых талантливых, и готовы затянуть в своих липких сетях на дно весь коллектив.
Ну правильно — война, только увольнять и ни разу не стесняться. Вы конечно же во всём правы.
А разработчики, особенно прочитав ваш комментарий, намотают на ус — война должна быть тайной. И очень холодной. Иначе сразу уволят.
А разработчики, особенно прочитав ваш комментарий, намотают на ус — война должна быть тайной. И очень холодной. Иначе сразу уволят.
Разработчик приходит в компанию для удовлетворения собственных интересов, для того, чтобы зарабатывать деньги и повышать за счёт этого качество своей жизни, для удовлетворения своих потребностей, а также профессионального роста. Если человек приходит ради войны — ему действительно не место на этой позиции.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Гибкие методологии: взгляд со стороны бизнеса (часть 1)