Сбор информации
В компании уже пробовали внедрять scrum, по-началу он заработал, но потом что-то пошло не так и он сошел на нет. В итоге вернулись к иерархии вроде такой: руководитель направления, замы руководителя, руководители групп тестирования, разработки и аналитики с ручной раздачей задач и узкой ответственностью каждого сотрудника.
Первым делом, естественно, требовалось провести диагностику — почему собственно не сработал scrum. Выбрал два способа диагностики: опрос и исследование через незначительное изменение.
Опрос показал разделение людей на неравные группы:
- На небольшую часть сотрудников давил сильный негативный осадок. Они выражали крайнюю степень негатива по отношению к руководству и друг к другу.
- Примерно треть просто не верила руководству и в то, что что-то можно изменить. За время их работы в компании они уже пережили пару авралов и не видели от руководства мер, которые помогли бы избежать аврала в будущем.
- Треть не видела проблем, удивлялась, когда я говорил, что они сидят в одном кабинете, с людьми, которые видят БОЛЬШИЕ проблемы.
- И остальные — студенты. Они не знали, что такое хорошо и что такое плохо и потому просто как-то работали.
- Еще было пара человек, которые относились к работе вполне позитивно, активно и с азартом выполняли возложенные на них обязанности.
Исследование через незначительное изменение
Суть исследования сводится к тому, чтобы потыкать и посмотреть на реакцию.
Под удар попало в основном незначительное улучшение быта: кухня, стартовый набор новичка, кружки с корпоративной символикой, наушники, витаминки, канцелярия. Данные изменения обосновывались руководству необходимостью работать над корпоративной культурой: поднимать репутацию компании в городе и поднимать лояльность сотрудников с помощью проявления заботы. «Потыкивания»намеренно выставлялась напоказ для того чтобы вызвать более интенсивную реакцию как руководящей верхушки так и рядовых участников.
В процессе внедрения незначительных изменений столкнулся с интересными фактами:
- Инертностью конкретных должностных лиц — даже после достижения договоренности по своей воле мало кто что-то сделал, всех приходилось активно педалировать.
- Некоторые должностные лица отнеслись к внедряемым изменения откровенно негативно — хотя при разговоре лицом к лицу или согласно кивали или просто молчали.
- Некоторые незначительные изменения вроде витаминок должен был утверждать лично он Сам.
- Некоторые рядовые сотрудники восприняли мои инициативы положительно, некоторые остро негативно.
- Некоторые рядовые и не только сотрудники донесли до меня, что предлагали то же самое что и я, но были, по меньшей мере, проигнорированы.
Предварительные выводы
В ходе исследований я понял, что проблемы подразделения, куда меня занесло, находятся вовсе не в подразделении, а в во всей компании целиком — в бухгалтерии, в хозяйственной части, в высшем руководстве, в рядовых сотрудниках. Проблема просто ровным слоем распределена по всей компании. Тогда я понял, что копать нужно в сторону такой вездесущей субстанции как корпоративная культура. Я попытался формализовать проявление корпоративной культуры и ее суть как советовал Эдгар Шейн. Я постарался описать артефакты (внешние проявления) корпоративной культуры, заявляемые ценности и докопаться до базовых представлений участников компании. Т.к. это был мой первый анализ корпоративной культуры, прошу отнестись к его результатам снисходительно.
Артефакты:
- Мы это пробовали, это не работает — частый ответ на предложения и инициативы.
- Одни правила работы с jira и git для всех подразделений.
- Личное участие в согласовании витаминок и наушников его Самого.
- Запрет распространения негативной информации.
- Нет свободной информации о должностях.
- Отсутствие взаимопомощи.
- Отсутствие инициативы от сотрудников за редким исключением.
- Жесткий график работы.
- Перегруженность руководителей.
Провозглашенные ценности:
- Самое главное — клиент.
- Подчинение.
- Регламент.
- Стандартизация.
Базовые представления:
- Человека легко заменить.
- Люди не хотят работать по своей воле.
- Быт не влияет на производство.
- Сила организации заключается в её регламентах.
- Принимают решения только руководители.
- Сотрудники некомпетентны.
А был ли scrum?
Изображение ниже иллюстрирует моё отношение к внедрению scrum в описанном выше контексте.
Недавно наткнулся на подборку разного рода манифестов, связанных с разработкой ПО. Тогда, посмотрев их все, я утвердился во мнении, что основой любого agile фреймворка является максимальное использование компетенций каждого сотрудника. Тут надо сделать небольшое отступление, чтобы мы все одинаково представляли себе agile. Agile это не только способ управления задачами и требованиями и его суть не в итерациях. Его суть в непрерывной адаптации всего ко всему: требования, коммуникации, инструменты, процессы и т.д., — не даром где-то рядом с термином «agile» стоит термин «самоорганизующаяся команда». Так вот достичь непрерывной адаптации можно только в особых условиях, с особыми отношениями в коллективе:
- Инициативы важны и приветствуются.
- Проблемы отдельного человека — проблемы всей команды.
- Эксперименты всячески поддерживаются.
- Ошибки неизбежны. Мало того, они полезны т.к. с их помощью команда приобретает опыт. Быстро ошибаемся, быстро учимся, быстро улучшаемся.
- Профессиональные цели каждого человека известны и учитываются.
- Доверие лежит в основе отношений в коллективе.
- Свободное выражение мнения.
- Психологическая безопасность (по мнению google это основной фактор успешности проектов и команд).
Agile возможен только в условиях, где каждый человек важен. Если это не так, то даже применив все практики scrum, ты получишь всего лишь инструмент управления задачами, но это не будет agile. Agile не подразумевает какую-то определенную статическую структуру или замороженные процессы, нет, ни в коем случае. Если вдруг ты с радостью обнаруживаешь, что изобрёл идеальные процессы и структуру компании — не пройдет и пяти лет как вам пора будет на свалку. Естественно, речь идет только о разработке ПО, на заводах актуальность процессов теряется значительно медленнее (это предположение). Agile это состояние группы, в котором она постоянно меняется для адаптации к постоянно изменяющимся условиям. Состояние agile заключается в понимании, что как только вы остановились в развитии и перестали экспериментировать, то сразу начинаете становиться неактуальным и не за горами тот день, когда ваша компания развалится.
А теперь вернемся к изучаемой компании. Как только тебе отказали два раза без внятного, на твой взгляд, объяснения причин, как только на тебя пару раз повысили голос, как только тебя оставили один на один с твоими рабочими проблемами и не помогли в критической ситуации — ни о каком agile больше речи не идет. Ведь вы больше не станете открыто говорить о проблемах (потому что проблемой являются люди, которые вас спрашивают о проблемах), вы не станете проявлять инициативу (вы уже попытались, но были, как минимум, проигнорированы), вы не поможете своему коллеге (ведь он не помог вам), и больше ни о каком развитии компании или отдельной команды уже не может идти речи. Увы — вы уже плохо пахнете и местами покрылись трупными пятнами.
Так что… применяя scrum, не забывайте об agile!
Комментарии (48)
teemour
16.12.2017 12:11Очень интересно почитать как удалось заставить людей помогать друг другу
LaserTower
16.12.2017 18:44Работая в одной из компаний ввели коллективные премии:
Если план на команду выполнен, то все получают премию, нет — нет.
yizraor
16.12.2017 21:40Кхм, я некомпетентен в Scrum и Agile, публикацию прочитал с интересом, и Ваш комментарий тоже :)
Но вот вопрос — а описанная из Вашего опыта практика коллективных премий насколько была успешна, и не было ли проблем? И если были проблемы, то как решались?
Прошу прощения, но что-то мне сразу в голову настойчиво стучится следующий сценарий: есть некая "команда" из, допустим, 5-и человек. Из них 3-е поддержали предложенное "социалистическое соревнование", выкладываются по-полной, чтобы получить желанную премию. И парочка халявщиков, которым плевать. Ну вот плевать и всё: типа "вам надо, вы и рвите себе жилы, а мы будем как прежде работать — и это в лучшем случае, если не будете на нас возникать; а будете звиздеть (черепаху из анекдота помните?) — так вобще ничего делать не будем, и работайте втроём за пятерых — а мы всё равно с вас будем премию иметь!".
Если подобный сценарий случится, то ведь дело запахнет расслоением коллектива и множеством конфликтов между "активниками" и "халявщиками"… "Активные" захотят, как минимум, отмежеваться от "халявщиков", требуя перетасовки людей по разным командам, желая работать с себе подобными, ну а "халявщики" соответственно будут против — иначе с кого же им премии иметь :)
А ещё могут найтись "личности", которые ради скорости выполнения планов будут жертвовать качеством кода, и в итоге качество всей самой системы через какое-то время начнёт падать, а сложность (/время/стоимость) разработки со временем станет повышаться… И ведь все эти проблемы тоже как-то надо решать...
DenisSilvers
17.12.2017 04:17Вы не учитываете лидера. Обычно лидер использует свое влияние для того, чтобы привести команду к единому пониманию. Если у лидера в команде 3 человека трудятся, а 2 фрирайдят — то это не команда, а что-то другое.
Но даже и без учета лидера, кто деливерит — тот и заказывает музыку.
Dr_DelProg
17.12.2017 08:20Ежедневный стендап со стандартным вопросом (среди прочих) "Какие проблемы возникли?" помогает научить людей взаимопомощи. Обычно команда накидывает идей и старается помочь. Если конечно в команде не одни упыри, которые отмалчиваются и всегда не знают что посоветовать. Но такой жопности, я думаю, достичь удастся не многим, ибо это уже смерть команде.
Ещё мы дедали по два стендапа в день, чтобы чаще происходила коммуникация — в обед и вечером. Это пока команда не сыгралась.
saterenko
18.12.2017 10:34Очень интересно почитать как удалось заставить людей помогать друг другу
Заставить помогать — это сильно… Невозможно заставить делать добро…
khim
16.12.2017 13:10Поставил плюс, хотя статья, конечно, недописана.
Будем ждать продолжения… любого. Даже если не получится — всё равно интересно. А то про то, как у них всё классно получилось — пишут все, а как «рассыпаться» начинает — никто.
Дальше — «ошибка выжившего» и далеко не факт, что правильные советы…
imxo2
16.12.2017 18:29Отличная статья, даже для таких как я ещё студентов, так как один из самых больших страхов выпускников, это тот, что пройдя собеседование он окажется 1 на 1 со сложными новыми задачами и не справится, или справиться с лишком медленно и его за это выгонят.
a-bobkov
16.12.2017 18:29Корни всех проблем — в голове собственника, а про него как раз ни слова. Копайте глубже!
SbWereWolf
16.12.2017 22:05+1
сколько фирм сменил, во всех одна история — люди во всём транслируют отношение директора, и это не переломить, директор сам себя не поменяет, другого не поставят :) так что только валить из таких мест. только беда что везде такая петрушка :)
Foxcool
16.12.2017 19:04Когда впервые столкнулся с внедрением эджайлов и скрамов на описанный манер, то сначала все это возненавидел. В понимании многих менеджеров эти практики просто подразумевают тонны отчетов и коммуникации, возможности жестко вручную управлять специалистами, на хожу меняя задачу и т.д., а не про устранение иерархии, развитие инициативы, гибкость процессов и прочие описанные прексрасные свойства. Только потом почитав какие-то ститьи и книжки я понял, что, оказывается, проблема не в идеях, а в людях и реализации. Тут как с емократией — в идеях и бумагах подразумевается светлый мир, а на деле что имеем, то имеем. (:
UnDelete
20.12.2017 03:26Вот кажется это ценное мнение. Столкнулся с такой же проблемой. Пришел скрам мастер, и не смотря на то что он проповедовал взаимоуважение и командную работу, привел всех к формализму, который был только у него в голове. И вместо развития, я столкнулся только со стогнацией (не скажу про команду, только про свою). И так как все мои попытки не привели к изменению ситуации, пришлось покинуть эту фирму.
aosja
16.12.2017 21:38Agile это не только способ управления задачами и требованиями и его суть не в итерациях. Его суть в непрерывной адаптации всего ко всему
Частые изменения не являются зоной комфорта для многих людей (естественное, мое мнение). Были у нас такие ковбои методологии, что-то постоянно меняли: «А почему у вас нет клевой доски для развешивания задач на бумажечках? А что-то не видно, кто делает задачу. Аватарки на бумажках будет само то! А что это у вас разработчики БД не пишут CSS для фронтенда? Как-то не эджайл… Нам нужен ретроспектив, на котором мы укрепим работу команды построением башни из макарон!»
Когда заезжие гастролеры наконец-то оставили нас в покое, люди начали заниматься тем, для чего их нанимали: писать код,… ь.
А когда люди стали заниматься любимым делом, то они стали проявлять инициативу.
vershov
16.12.2017 23:09Жизнь слишком коротка, чтобы просиживать ее в зоне комфорта.
aosja
16.12.2017 23:16А, ну да, надо обязательно «в гамаке и на лыжах»(с) Комфорт, это когда ты получаешь удовольствие от работы. Что здесь плохого?
khim
16.12.2017 23:38Комфорт, это когда ты получаешь удовольствие от работы. Что здесь плохого?
Ничего если ваша задача — работа на конвеере. Неважно каком: конвеере по выпуску автомобилей или web-сайтов на Wordpress'е.
Однако если от вам требуется выпускать что-то новое регулярно, то, увы, работа в зоне комфорта не годится: нельзя научиться ничему новому не набив шишек.
И вот это-то изначальное деление, как правило, при внедрении Agile, Scrum'а и прочих всяких «модных» методик пропускают.
Либо пытаются организовать из «середнячков заточенных под „не высовываться“» инновационную компанию (а это не работает), либо заствляют людей, ориентированных на новинки «строем ходить» (это работает — но с отвратительным КПД).aosja
16.12.2017 23:53Однако если от вам требуется выпускать что-то новое регулярно, то, увы, работа в зоне комфорта не годится
Часто работаю над чем-то новым и интересным в отличной команде. Если команда занята чем-то серьезным, то скрам-мастер предоставить возможность выбора: стендап сейчас, позже или сегодня не нужен. Новые фичи продакт-менеджер приходит просто обсудить в комнату к команде, когда это надо, а не парит заранее назначенными на полгода вперед митингами груминга.
Это моя зона комфорта, это agile, а не та хайповая фигня, которую нам тюхали до этого.justboris
17.12.2017 01:09Если команда занята чем-то реально серьезным (аврал или сломалось что), то и у скрам-мастера есть чем заняться и на стендапы отвлекать никто не будет. Если давать возможность выбора, в большинстве случаев ответ будет "стендап не нужен".
- То есть вы предпочитаете, когда к вам внезапно врываются и прерывают рабочий процесс, чем заранее назначенное время для разговоров о будущих фичах?
vershov
17.12.2017 00:40Ничего плохого, кроме того что наш мир по своей натуре очень изменчив.
Слышал несколько историй немецких фирм, которые продают один продукт на протяжении многих лет и удивляются, что все приходит в упадок: «как так, это же работало на протяжении последних 20 лет».
Видел многих олд-скульных специалистов, которые были когда-то очень хороши в какой-то области знаний, но вместо того, чтобы учиться чему-то новому сидели в зоне комфорта и, в конечном итоге, перестали быть востребованными рынком.
Да, выход из зоны комфорта очень часто болезнен, но (человек — это такая скотина, что ко всему привыкает) очень скоро нахождение вне зоны комфорта становится достаточно комфортным.
rg_software
17.12.2017 02:26которые были когда-то очень хороши в какой-то области знаний, но вместо того, чтобы учиться чему-то новому
Проблема часто бывает не в людях, а всё-таки в технологии и её внедрении. Олдскульный специалист потратил многие годы для того, чтобы стать профессионалом в своём наборе технологий и рабочих практик. Переход на новые обязательно означает некоторый временный провал, поэтому совершенно рациональным поведением будет не делать этого, если мы не ожидаем в итоге существенного роста производительности. А он не всегда есть, т.к. многие новые технологии (не все, конечно) являются эволюционным развитием старых и лишь немного модернизируют процесс.
vryashentsev Автор
17.12.2017 08:25Грамотный коуч построит работу так что изменения будут идти от самих программистов. И тогда эти изменения будут комфортны и обоснованы. Насаждать изменения сверху — верный способ получить кучу негатива. Но есть одна вещь, которая требует насаждения, убеждения и прочих активных действий — идеология. Как только идеология непрерывной адаптации внедрена — всё, можно отходить в сторону и просто наблюдать.
aosja
17.12.2017 01:07Видел многих олд-скульных специалистов, которые были когда-то очень хороши в какой-то области знаний, но вместо того, чтобы учиться чему-то новому сидели в зоне комфорта
Учиться надо всю жизнь, но это не то, о чем я говорил в своем первом комменте и о чем веду речь. И швец, и жнец, и на дуде игрец — таких людей очень мало и нельзя просто скрамом нагнуть всех уметь делать все. «Архитектура должна разрабатываться под команду, которая ее будет реализовывать».
amberovsky
17.12.2017 04:21Некоторые должностные лица отнеслись к внедряемым изменения откровенно негативно — хотя при разговоре лицом к лицу или согласно кивали или просто молчали.
Мне кажется это такая прослойка менеджерского звена, которая «ни рыба, ни мясо». Они даже могут быть и линейными менеджерами, но по факту их роль выше, но ниже уровня, где можно принимать фундаментальные решения в их отделе. Такие должности могут возникать как в ответ на увеличение штата нижнего звена, так и под влиянием различных попыток хоть как-то исправить ситуацию.
В итоге формируется устойчивый костяк менеджеров, которые
— умело контактируют с топ-менеджерами (поэтому они с такой радостью вам кивают в ответ на предложение об изменениях — боссы хотят изменений и они обязаны делать вид, что их поддерживают)
— формируют круговую поруку и почти никогда не бывают виноваты
— транслируют линейным сотрудникам, что «ну, вы же знаете, какая у нас компания» и грамотно фильтруют ваш фидбек
Если такие люди находятся достаточно долго в компании, то всё становится очень плачевно — всё больше людей оказывается вовлечено, топы не готовы изменить почти весь «средний класс» менеджеров, линейные сотрудники всё видят и понимают бессмысленность изменений
lotse8
17.12.2017 04:22Если Сам утверждает витаминки и наушники, то у него нет времени думать о стратегии, в лучшем случае будет закрывать возникающие текущие проблемы. Фирма — корабль без карты и компаса. Взрослого человека (Самого) переделать вряд-ли удастся. Поэтому финал предсказуем на 98%. 2% на счастливый случай, что дело кому-то другому более толковому продаст или по наследству оставит.
zolt85
18.12.2017 11:33А я Вам скажу, что пошло не так со Scrum-ом.
Никто толком не разобрался в нем, прочитали buzzword-ы — спринты, покер, ретроспективы, демо, и начали лепить как умеем. Народ в панике, еще вчера все работали по плану индивидуальному, а сегодня пришло руководство и объявило «всеконторский Agile». Оценивать никто не умеет, в сроки не укладываются, спринты факапятся, заказчик злится.
«Ну чот не поперло», решило руководство, и придумало новую мульку, вернее откатилось к старой. И проходит некоторое время, а воз и ныне там. Оценивать никто не научился. «Долги» после Agile-а остались. После нескольких пожаров, и тушение их баблом, нормальные разработчики, болевшие душою за проект «сгорели» и решили уйти. А они с самого начала пытались донести до власть имущих позицию по разработке.
Проект вошел в фазу вялотекущего допиливания, докостыливани того, что уже утекло на продакшен. Заказчик немного ворчит, но уже потратил на Вас сотни нефти и искать новых исполнителей ему лень. Поэтому бабки есть и направление в общем на плаву. И нафига там кому-то напрягаться.
Вот так и делается Agile. Хотя, кто мешает поискать информацию, поискать людей знающих, почитать рекомендации, продумать план внедрения, и по-тихоньку претворять в жизнь, сначала в отдельно взятой команде, а затем и во всей конторе.
История является моим сугубо оценочным суждением, все совпадения случайны.
Gerda_W
18.12.2017 13:38Интересно будет прочесть продолжение истории, каким бы оно ни было. Но уже сам факт привлечения компанией специалиста по созданию команд позволяет сделать предположение, что не все потеряно. Удачи
71rmn
Заинтриговали… Чем дело то закончилось? Или еще в процессе? Продолжение будет?
vryashentsev Автор
Да, в процессе еще.
Думаю к лету может что-то получиться. Опишу и результаты и ошибки и, может быть, рекомендации.
nckma
Если не уволят.
igor_suhorukov
Если уволили за честность и попытки изменить ценности компании — значит хороший скрам мастер! Роль такая и риск есть, но он не должен останавливать.
Telichkin
А если за чесность и попытки изменить ценности компании уволняют программиста, значит ли это, что программист хороший?
khim
Нет — но и не значит, что плохой.
У программистов, как бы, ещё и другие полезные умения должны быть, кроме честности и попыток изменить ценности компании.
igor_suhorukov
Это ничего не говорит о профессиональных качествах программиста. Может говорит скорее о его небезучастности к тому месту где он работает и к не планктонным коллегам. И то при определенных условиях: что изменения направлены на оздоровление коллектива, что результаты изменений в будущем помогут бизнесу получать больше прибыли. Это как в balanced scorecard изменения не только для улучшения финансовых показателей…
Отличие от скрам мастера: программиста нанимают для разработки, а скрам мастера для улучшения процесса разработки. В нормальной организации скрам мастеру кроме обязанностей дадут и права на возможность изменения и улучшения. И сразу за инициативы не уволят. В конторах, которые «покупают Аджайл» ничего обычно улучшать не собираются — нужен маркетинговый булшит для клиентов.
Telichkin
А какие профессиональные качества программиста существуют в отрыве от процесса разработки? Спрашиваю не шутки ради, а потому что каждый человек по-разному представляет себе "правильный" набор профессиональный качеств.
Если говорить про веб и мобильную разработку, то лично мне сложно рассматривать профессионализм программиста в отрыве от процесса. Только лишь технические навыки не позволят выпускать продукт часто и с меньшим количеством ошибок. Если в компании принято "перебрасывать" продукт от программистов в тестирование и забывать о нем, то насколько бы хорошо программист не владел техниками написания тестов, его в такой компании скорее всего "сожрут", потому что он идет против существующих ценностей. Если в компании программисты отдают код в эксплуатацию и их не волнует его дальнейшая судьба, то новому программисту даже не дадут шанса провести созданный им код до боевого окружения самостоятельно, потому что это работа другого отдела. Если руководитель команды никому не доверяет декомпозицию user story, а только спускает на программистов конкретные задачи, то как бы программист не хотел взять на себя ответственность за оценку, декомпозицию и выполнение всей user story, ему эту ответственность не дадут, потому что он посягает на работу руководителя.
Или программист, который прикладывает все силы, чтобы выпустить в срок качественный продукт, который точно будет работать на боевом окружении — это ненастоящий профессионал?
Zebradil
Программист, работающий в команде, должен, как минимум, уметь работать с другими людьми, уважать коллег. Это значит, что нужно уметь договариваться, вырабатывать соглашения: как писать код, как комментировать коммиты, как работать с системой контроля версий в целом, как документировать свою работу. Нередка проблема, когда программист способный и производительный, но только если работает самостоятельно. Когда речь идёт о работе в команде, начинаются проблемы и появляются поводы для раздражения коллег.
Каждый член scrum-команды должен стремиться к достижению не личных целей, не к решению его персональных задач, но к достижению целей, поставленных перед его командой и к решению командных задач.
UnDelete
Я правильно понял, что вы предлагаете программистам молчать тряпочку и писать код, пока скрам мастер имеет право на изменения. Если программист будет инициативным, то его быстрее уволят чем скрам мастера, потому что от последнего это ждут.
Просто такое мнение кажется и рушит, то что скрам пытается построить. В итоге скрам-мастер для руководства становится "менеджером", а разработчик "исполнителем" и первый имеет право диктовать свои условия команде, а второй как бы нет.
igor_suhorukov
UnDelete конечно вы неправильно поняли. У каждой роли свой фокус. Давать отзыв и советы должна вся команда. Скрам мастер не менеджер, а роль ответственная за скрам процесс и его улучшения. К слову скрам мастер вообще не обязан уметь программировать, у него и без этого достаточно работы. То что совмещают роль разработчика и скрам мастера — не от хорошей жизни и часто вызывает конфликт интересов. И в скраме нет места менеджерам и PM — это попытки натянуть новый процесс на старый глобус
igor_suhorukov
То что вы описываете — как не должно быть, но происходит повсеместно. И как раз лежит в области убеждений собственников и негласных корпоративных ценностей. Иерархия же не может без бюрократии и привычного им процесса…
Telichkin
Если не читали Extreme Programming Explained: Embrace Change (2nd Edition), то очень советую с ней ознакомиться, особенно с главами, которые касаются ценностей и принципов. Книга почти полностью про взаимоотношения людей, а не про технологии и техники и в вашей ситуации может пригодиться. Вот несколько цитат, чтобы заинтересовать еще больше:
Обидно, что проводить такие эксперементы и менять культуру внутри компании позволяют только специальным людям, а не разработчикам.
vryashentsev Автор
Я как стараюсь вовлечь каждого для реализации изменений. Один человек тут не справится. Спасибо за рекомендацию.
Ol171
Может быть и изменение своего взгляда на вещи) Спасибо за рассказ с самого начала!