Блог:Максима Цепкова

Материал из MaksWiki
Перейти к: навигация, поиск

Профессиональный блог Максима Цепкова.

Ранее был на http://blogs.uml2.ru/blogs/maksiq и http://softwarepeople.ru/, затем на сайте компании http://lib.custis.ru/Blog-mtsepkov, а с 19.05.2014 переехал сюда.

Сейчас все посты из старых блогов скопированы на мой сайт, при этом восстановлены посты, утраченные при закрытии портала SoftwarePeople. Полный список статей можно посмотреть в оглавлении блога.

Я в соцсетях

http://www.facebook.com/mtsepkov
http://www.linkedin.com/in/mtsepkov
https://twitter.com/mtsepkov

У меня есть личный телеграм-канал https://t.me/mtsepkov

И личный ЖЖ http://maksiq.livejournal.com, там путешествия и другие мысли вне ИТ.

Последние посты


2018-04-19: Политэкономия Владимира Путина - книга китайских ученых

Прикольно :) Китайские ученые написали книгу «Политэкономия Владимира Путина», она переведена на русский. Это я узнал на Международном экономическом симпозиуме в СПбГУ здесь пленарная программа открылась круглым столом по обсуждению с участием китайских авторов. Они, кстати, по русски нормально говорят.

Я слушаю Гуань Сюэлин, соавтора. Там все всерьез. Авторы изучают уроки российской экономики, начиная с перестройки, чтобы извлечь уроки для китайской. В какой-то момент они зафиксировали целостность моделей Путина и решили написать книгу.

Неоимпериализм. Не только критиковать, но и исследовать альтернативные направления работы. Копировать системы развитых западных стран не только бесполезно, но и наносит ущерб. И надо строить свою экономическую систему реалистической экономики.

Политэкономия Путина - идеология Путина и российская экономическая практика. Падение цен на нефть и санкции - испытания, проходятся успешно.

Второй соавтор, Мэн Чжан, уже по-английски. В докладе - модельки, здоровая экономика, олигархическая и неоколониальная, в 2000-х в России была комбинация, сейчас это преодолено.

И еще интересно - они измеряли силу Путина по Макиавелли - глава 10 Государя, там про kpi правителя (говорят). И сравнивали Россию с Бразилией

Из выступлений - особый интерес для китайской экономики представляют российские практики отступления от неолиберальной модели. А политэкономия Путина (как модель и практика) ставится соразмерной с экономикой Рейгана, Тэтчер и Синдзо Абэ.

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

Пользуясь случаем, купил себе бумажную книгу и подписал у авторов. Обещано, что электронная вот-вот будет на litres.

2018-04-15: CodeFest - конференция моей мечты

C Кириллом Улитиным на моем докладе

Две недели назад был в Новосибирске на #CodeFest. И очень доволен, я бы сказал, что организаторы сделали конференцию моей мечты - с большим количеством обзорных докладов от экспертов, которые раскрывают современные трендовые темы. При этом не поверхностно, а с погружением в детали, да еще складывая мозаику разных трендов, про которые, в общем-то, знаешь в целостную картину. В этом и ценность - когда тема на хайпе, то достаточно сложно получить целостную картину, прорываясь через поверхностное представление, хайповый флейм и отдельные аспекты. Если плотно следишь - ты в теме, но вот на это время не всегда есть. Доклады на конференции были разной ширины темы - и общий доклад по искусственному интеллекту от Ивана Ямщикова, и доклады по конкретным современным фреймворкам и работе с ними, но в любом случае спикеры показывали очень глубокое знание темы, давали не только общие концепты, но и детали.

Наряду с большим количеством технических потоков, были потоки про управление и лидерство, что, в общем-то не удивительно на современных IT-конференциях, как писал полгода назад, IT стремительно и всерьез осваивает soft skill. Если говорить об охвате тематики по площади, то, наверное, не хватало потока аналитиков, но вполне возможно, что для аудитории конференции это не очень актуально. В любом случае, восемь параллельных треков и 2500 участников - это очень круто, конференция - растет. И я очень благодарен организаторам за приглашение выступить.

→ продолжить чтение…

2018-04-14: впечатления с KazanEventExpo

Волею судьбы, а вернее, по приглашению организаторов, рассказывал про Agile и другие новые технологии менеджмента на #KazanEventExpo. Они услышали мой короткий рассказ в январе на форуме #EFEA и Линара Бурханова пригласила меня выступить в Казани, рассказать уже полный вариант, чтобы люди смогли сами разобраться и оценить уместность применения. С моей точки зрения, сейчас для event-индустрии идет период освоения технологий и становления технологичного создания событие и мероприятий, и часть лидеров это уже сделало, а другие работают на личном умении, при котором каждый эвент - героическое деяние, но и те и другие смотрят на новые технологии. Простые методы Agile в прямом виде тут применимы достаточно ограниченно, а отдельные практики, такие как ретро по проектам - и так применяются и можно осваивать приемы технологизации. Но тем важнее широкое концептуальное понимание для людей, которые смотрят широко и думают о заимствовании разнообразных практик. Поэтому рассказ был длинный, на полтора часа, слушали с интересом. Презентация доступна по ссылке http://mtsepkov.org/NewMng-KEE

Я же хочу рассказать о другом. Мне было приятно на мероприятии увидеть людей, которые всерьез ставят задачу по превращению Казани в туристический центр, понимая ее сложность - ведь в Казани нет ни моря ни гор, ни суперских туристических достопримечательностей: это не только не Париж, но и не Верона. И не просто ставят, а движутся к ее выполнению, начиная с Универсиады (а может, и ранее). Не формально отрабатывая поручения, а изыскивая и изобретая различные возможности, оригинальное позиционирование. И отмечая этапы продвижения и свою конкурентную позицию относительно других городов и местностей. Кстати, говорят, что по номинации архитектура в опросах booking.com Казань уже обошла Петербург, хотя Москва - лидирует. А то, что эти люди работают не только в коммерческих компаниях, но и в госструктурах - меня тоже радует. При этом я вовсе не хочу сказать, что все идеально и прекрасно, и остались только отдельные недостатки. Но я с удовлетворением отмечаю достаточно много позитивных моментов.

И, продолжая тему, хочу рассказать одну простую вещь.

Стать лучшим - очень просто, всего три пункта:

  1. Надо считать себя лучшим
  2. Надо, чтобы другие считали тебя лучшим
  3. И надо просто быть лучшим

Важно найти в себе силы и амбиции начать с первого пункта, а не отложить его на конец. Но и не остановиться на первом пункте, как тоже бывает.

А еще надо верно выбрать масштаб и позицию. Поскольку многие технологии, и в event-индустрии, и в других областях, например, в Agile, сильно продвинуты на Западе, то есть прямой смысл использовать готовые технологии. И можно выбрать позицию последователя, поставив задачу стать лучшим транслятором технологий. А можно выбрать другую позицию: понимая, что перенос технологий неизбежно потребует их адаптации, поставить перед собой задачу отрефлексировать эту адаптацию и вернуть ее тем, кто развивает технологию, став одним из 20-50-100 человек в мире, которые развивают отрасль. Эти позиции внутри России могут отличаться слабо, а вот на уровне мира - очень сильно. И в какую позицию ты становишься - это вопрос твоего выбора.

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

2018-04-14: год группе ГосAgile

Уже год официальной работы рабочей группы по применению гибких методологий в гос.проектах (#gosagile) - фото с ее первого заседания было в этом посте год назад, а я писал об этом заседании здесь http://mtsepkov.org/GosAgile-2017-04 Есть продвижения по методическим рекомендациям, еще в октябре был проект для обсуждение и идет не слишком быстрый процесс согласования (пост). Однако, главное - совсем другое, а именно большой практический интерес, который проявляется к Agile-методам в различных гос.организациях, которые традиционно воспринимаются как достаточно консервативные. На #Agiledays было много докладов, например, очень интересный доклад Центрального Банка об их кейсах внедрения Agile в операционных департаментах (не IT) и при проведении изменений, с цифрами, показывающими существенное ускорение сроков выполнения задач (иногда - в разы, проект создания одной распределенной внутренней структуры ЦБ оценивался как "полтора года - оптимистичный минимум", а по факту через несколько месяцев эта структура начала работать). Так что практика - развивается и быстро.

2018-04-11: рассказывал про Agile экономистам и логистикам

Вчера (10.04.2018) рассказывал про Agile и новый менеджмент сразу на двух мероприятиях: Всероссийском Симпозиуме «Стратегическое планирование и развитие предприятий» в ЦЭМИ и на Первом Конгресс руководителей и специалистов по логистике и цепям поставок компаний — производителей и ритейлеров. С логистиками мы договаривались давно, три недели назад я подробно рассказывал про новый менеджмент на встрече сообщества логистиков. А выступить на Симпозиуме меня позвали неделю назад.

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

В докладе для ЦЭМИ есть еще тезисы выступления, которые, впрочем, не получилось раскрыть за 7 минут в полном объеме. Видео симпозиума ожидается, а пока интересующиеся могут посмотреть осеннее выступление Agile и бирюзовые организации - два пути менеджмента в мир третьей волны (Круглый стол в SPb 2017-11), и, заодно, сравнить слайды - они развиваются, и содержание - тоже. В доклады Что могут практики Agile и холакратии и нужны ли они Вашей организации (ПиР-2017) и Agile и игрофикация: за каким менеджментом будущее? (AgileBusiness-2017) раскрывают тему подробнее.

А я хочу отметить, что в обоих случаях выступления вызвали интерес и вопросы. И это были не единичные выступления по новым технологиям управления.

На Симпозиуме, помимо меня, выступал Александр Горник, рассказывая опыт самоуправления MindBox, с многочисленными ссылками на Фредерика Лалу. Это выступление было на пленарном заседании, а потом - продолжилось на круглом столе. О практиках самоуправления бирюзовых организаций рассказывал Олег Клименко (этого выступления я не слышал, убежал к логистикам). И вопросы ко всем звучали показывали позицию "с этим имеет смысл разобраться", понять механизмы самоуправления и разделения ответственности, позиции "это сказки, которые не работают" - я не услышал.

У логистиков после меня выступал Станислав Морозов, руководитель логистики в России из General Electric Global Operations и рассказывал о применении Scrum для проектов изменений, и о планах дальнейшего развития применения Agile в компании - успешный опыт вызвал интерес и у других подразделений. А потом была панельная дискуссия руководителей из разных компаний, которые рассказывали о своем опыте и оценивали применимость новых подходов. В одних организациях, например, в МТС Agile уже широко применяется и известен, в других - активно смотрят и интересуются, кто-то полагает, что на уровне интенций именно так и работает, и потому практики могут оказаться полезны. Кстати, многие хорошие руководители по принципам работы действительно работают близко к Agile, и тезис о том, что правильная позиция руководителя - это коуч-наставник не является специфической для Agile-мира или бирюзового мира. Но там к этому добавляется управленческая технология, которая именно в эту позицию ставит и препятствует отступлению от нее, в то время, как в традиционных иерархических структурах такая позиция лишь возможность и дело выбора. А еще я хочу отметить, что цветовые уровни Фредерика Лалу являются рабочей схемой у многих из тех, кто выступал на панели, по ним оценивают организацию и сотрудников, в их терминах говорят о проблемах и текущем развитии. И это меня очень радует.

Возвращаясь к Симпозиуму, хочу отметить, что мне было очень интересно послушать пленарное заседание. Владимир Козлов (генеральный директор Аналитического центра «Эксперт Юг», профессор Института филологии, журналистики и межкультурной коммуникации Южного федерального университета), рассказsdfk о практиках фасилитации развития предпринимателей и предприятий мелкого и среднего бизнеса через обсуждение их стратегии с другими такими же предпринимателями. Это не имеет прямого отношения к бирюзовым организациям, однако работа через сообщества, коллективные обсуждения и фасилитацию - тоже из арсенала нового мира.

Интересный доклад был Георгия Клейнера (член-корреспондент РАН, заместитель научного руководителя ЦЭМИ РАН) - он рассказывал о том, что в современном мире уже неправильно говорить о предприятии как об изолированной ячейке экономической и хозяйственной деятельности, потому что связи с внешним окружением становятся сильными и надо говорить об экосистемах. Правда, я не понял из доклада, является ли такой разговор пока лишь метафорой и интенцией, или уже можно говорить об успешном переносе моделей из экологии и биологии на экономику и социальные науки. Кстати, бирюзовые организации ведь рассматривают организацию именно в метафоре организма и его эволюции, а про рабочую группу говорят в метафоре клетки.

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

Любопытный доклад был у Александра Некипелова (академик, директор МШЭ МГУ им. М.В. Ломоносова) «О целевой функции капиталистической фирмы». Александр задался вопросом, с какого времени экономисты неявно сменили в своих моделях целевую функцию и начали говорить о максимизации прибыли вместо максимизации возврата капитала (ROI)? Произошло это недавно, начиная с Маршалла и неоклассиков. И, кстати, с моей точки зрения имеет внеэкономическое обоснование, а именно дает для крупных корпораций преимущество в рейтингах, маскируя их упадок с выходом в аристократизм и бюрократию (используя фазы жизненного цикла корпорации по Адизесу). А еще максимизация прибыли делает математику проще. Но, оказывается, что если поменять целевую функцию и применить для новой те же математические модели, что и для предыдущей, то выводы будут парадоксальны, например, спрос на физический капитал перестает зависеть от его цены. И, с моей точки зрения, такие результаты ставят вопросы обоснованности неоклассических моделей экономической науки как таковой, даже независимо от критики ее со стороны тех, кто видит расхождение моделей с действительностью и тех, кто говорит, что модель рационального экономического субъекта не может служить адекватным приближением к реальным субъектам, в отличие, например, от модели материальной точки в физике в качестве моделей объектов мира.

А Виктор Полтерович (академик, руководитель научного направления ЦЭМИ РАН) в своем докладе говорил о связи идеологии и науки. О том интересном эффекте, когда некоторые научные модели становятся основаниями для разработки стратегий развития компаний и стран. Потом, в ходе исследований и практики применения может оказаться, что модель не учитывала каких-либо существенных факторов и имела ограничения, об этом выходят исследования. Но модель уже становится идеологией определенных организаций, которые успели стратегически построить свою деятельность на ее применении и исследования игнорируются. Ситуация усугубляется еще тем, что многие исследования ведутся на гранты, и финансирование со стороны подобных организаций выделяется лишь на те исследования, которые подтверждают их модель. И была ссылка на статью Martin Paldman, в которой тот приводит издевательскую модель рационального экономиста, желающего публиковаться и показывает, в какой мере тот должен будет искажать результаты исследований при нынешней организации науки и системы публикаций :)

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

Был и ряд других интересных докладов, так что я рад участию в Симпозиуме не только как спикер, но и как участник и слушатель. Впрочем, я слушал только часть, а про продолжение у Александра Горника в этом посте - совсем другое мнение.

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

2018-04-03: Спиральная динамика и культуры организаций от Марка Розина

Экопси выпустил очередной номер собственного журнала, темой которого стала Спиральная динамика применительно к Корпоративной культуре. Журнал доступен по ссылке к посту Марк Розин, которым я делюсь. Мне была интересна не только статья самого Марка "Путешествие по спирали 2.0", в котором он описывает культуры компаний разного уровня Спиральной динамики, но и ряд других статей и особенно достаточно детальный разбор ситуаций внедрения Agile в компаниях с разной корпоративной культурой. И я рекомендую интересующимся Спиральной динамикой почитать журнал, чтобы соотнести взгляд авторов со своим пониманием.

Для себя отмечу те моменты, в которых изложение Марка отличается от моей интерпретации Спиральной динамики. Не потому, что моя кажется правильной, а, скорее, чтобы учитывать эти различия в разных коммуникациях. И вопрос к тем, кто прочтет - а что думаете Вы, каковы Ваши интерпретации?

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

2) Культура согласия зеленого уровня у Марка ближе к оригинальному пониманию Бека и Кована, чем моя интерпретация. Моя позиция сильно ближе к тому, как понимает зеленый уровень Фредерик Лалу, который говорит о контрпродуктивности зеленого уровня. Я объясняю эти различия тем, что образ зеленого уровня был сформирован довольно давно, а с тех пор развитие шло вперед, он стал более массовым и потому мы явственнее можем увидеть разницу между ним и последующим, желтым уровнем. Кстати, об отличиях и акцентах уровней Спиральной динамики и Фредерика Лалу я писал в своем конспекте книги http://mtsepkov.org/Lalu

3) Про уровень, который идет вслед за зеленым у Марка написано "Культура синтеза", и идет объединение двух старших уровня Спиральной динамики - желтого и бирюзового. На мой взгляд, это неверно. Такой подход завершает развитие, а общий концепт Спиральной динамики говорит о его продолжении, просто отмечает, что на нынешней стадии мы не видим, что будет в будущем. Далее, конструкции желтого и бирюзового (turquoise) уровней уже можно относительно четко различать в тех организациях, которые находятся на фронтире. При этом Лалу описывал именно желтый уровень Спиральной динамики, он явно об этом говорит, просто приписал ему цвет teal, заимствованный из интегрального подхода Уилбера, а уже переводчик превратил его на русском в бирюзу. Кстати ,в одной из презентаций Марка я видел обозначение желтого уровня как "культура творчества". Это лучше соответствует моему восприятию желтого уровня, при этом следующий за ним я бы определил как культура развития.

4) Я не считаю, в отличие от Марка и самих авторов Спиральной динамики, что развитие по уровням обязательно последовательно. Мне ближе концепт Анатолий Баляев (Anatoly Balyaev), который говорит о звучании разноцветных струн. Что, естественно, не отменяет справедливости тех слов, которые у Марка написаны про мимикрию культур.

Что касается статьи Анастасия Попова (Anastasia Popova) про внедрение Agile, то там, на мой взгляд, довольно точно подмечены культурные противоречия между Agile-mindset и культурами разных уровней и вытекающие из этого проблемы.

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

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

2018-03-28: Шесть лет статье "Agile как IT-форма современного менеджмента"

Facebook напомнил, что то представление об #Agile, которое я даю в нынешних лекциях и докладах, например, на лекции во ВШЭ http://mtsepkov.org/Agile-HSE-2018 я впервые сформулировал 6 лет назад после AgileDays-2012 в статье, опубликованной на портале SoftwarePeople. Указанная в посте ссылка на статью сейчас не работает, но статья доступна на моем сайте Agile как IT-форма современного менеджмента В общем-то, интересно сравнить свое существующее понимание с тем, старым, и осознать, что концепт изменился не сильно, но появились новые основания и более глубокое понимание.

2018-03-27: AgileDays-2018 - мощное расширение Agile-мира

Прошла очередная, уже 12 конференция #AgileDays. Как и прошлые конференции, она позволяет составить релевантное представление о жизни Agile-сообщества России, которое за последние пару лет характеризуется мощным развитием, и продвижением за пределы IT-отрасли, включая использование Agile для организации работы госорганизаций, освоение практик бирюзовых организаций, а так же мощное освоение soft skill. Об этом свидетельствует и более 1500 участников конференции.

Но, вместе с тем, на ряде докладов возникает стойкое ощущение де жа вю: тебе рассказывают про поиски пути и решение проблем, о которых ты слышал 5 и более лет назад на прошлых конференциях. И проблемы эти часто связаны с неверным или неполным пониманием agile-фреймворков. Например, с отказом от роли Scrum Master и возлаганием его функций на Product Owner, становящихся очень похожих на продуктовых менеджеров. С понятным результатом: в одних командах проваливается продуктовый фокус, другие - не могут соорганизоваться, третьим - везет, они оказываются слаженные, а PO держит продуктовый фокус. В общем-то все эти результаты можно было предсказать, а не неожиданно обнаруживать...

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

И здесь надо отметить, что в принципе такая ситуация закономерна в период ажиотажного спроса на новые технологии - а с технологиями Agile мы сейчас имеем именно такую ситуацию. И она связана не только с рекламным hipe, модой и поисками волшебной таблетки, она объективна, поскольку вызовы, приведшие к возникновению Agile в IT идут в другие отрасли. Впрочем, об этом можно прочесть в моей статье Agile - ответ на вызовы нового мира, а здесь я не буду углубляться в тему.

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

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

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

  • Первый - рассказ о применении Канбана в Центральном банке, при чем не в IT, а в функциональном подразделении. Очень по делу, с крутыми фишками по организации Kanban-доски, и ясным пониманием решаемых задач, и представлении о достигаемом эффекте. Agile-методы тут выступают как средство, и их внедряют для более эффективной работы, а не для отчета.
  • Второй - рассказ Павла Рабиновича о применении Agile в школе для организации уроков. Который вписан в существующее нормативное* регулирование школ - оказывается, оно нормирует результат и форму его проверки, а не процесс, который вполне можно перестроить. И особенно импонирует целевая аудитория: речь идет не об элитных школах, действие развертывается в рядовых подмосковных школах, а эффект измеряется из сравнения успеваемости того же класса с тем же учителем при старой организации и при новой - при том, что успеваемость проверяется теми же самыми контрольными работами, они не реорганизуются, потому что являются нормативно определенной формой контроля результата.
  • А еще был замечательный доклад Александра Горника о бирюзовой организации MindBox с открытыми зарплатами, раскрывающий способы* самоуправления, и путь, которым они постепенно шли к открытым зарплатам, выравнивая перекосы.

На этом я, пожалуй, закончу обзор, и далее соберу те посты на FB, которые я делал на самой конференции. Как обычно, хочу отметить, что я слушал, наверное, 1/8 от общего числа докладов, во-первых, потому что параллельно шло 5 треков конференции и можно было быть только на одном, а, во-вторых, главное на конференции, все-таки, не доклады, а общение, которого у меня было очень много. И на часть интересных докладов я не пошел, потому что на других конференциях уже слышал примерно об этом и предпочел неизвестное. А доклады можно послушать потом, в записи. Хотя, надо отметить, ыто уже несколько лет ScrumTrek ленится и обрабатывает только лучшие доклады конференции, а не все. Это, на мой взгляд, - неправильно, потому что выбирая между докладами на конференции, где часто параллельно идет несколько интересных докладов, ты рискуешь не услышать нужного тебе. Я надеюсь, что все-таки вернется практика выкладывания всех докладов.

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

AgileDays-2018-sс1a.jpg AgileDays-2018-sс2a.jpg

→ продолжить чтение…

2018-03-18: Прошел ITGM-12

Прошел двенадцатый IT Global Meetup - очередная встреча IT-сообществ Санкт-Петербурга. Помещение, в котором проводили расширилось, добавился еще один зал - и потому участников было больше, чем в прошлые разы - 850 участников. Было много интересны докладов, и очень много общения. Дальше - мои впечатления о докладах.

Доклад "Blockchain для корпоративных решений: варианты применения" - хороший концептуальный обзор технологии blockchain - общие составляющие (распределенность, блоки, транзакции и др.), точки вариации - алгоритмы консенсуса (ресурсные и голосовательные в разных вариантах) и содержание транзакции, смарт-контракты как транзакции, содержащие вызов кода, который тоже хранится в системе и варианты версионирования и сохранения данных в реализациях. И платформы (hyperledger, ethereum, finchain), которые дают готовые реализации и позволяют строить свои в разных вариантах. С преимуществами, проблемами и примерами применений. На мой взгляд, если представить учебник по blockchain, то в докладе - введение в каждую из глав. При этом учебника по blockchain - нет, потому что технология развивается и учебник непрерывно дописывается. И в этом смысл доклада - он позволяет в целом, в контексте твоего проекта понять - стоит посмотреть на применение blockchain в конкретном варианте для них, наряду с другими, или смысла нет. Естественно, об этом есть статьи, могут быть альтернативные способы знакомства. Но мне доклады на конференциях нравятся больше. Спасибо Александр Урмазов (если я верно записал имя, в программе нет :( )

Ping yourself Ирина Матвеева на островке СПб СоА (Сообщество аналитиков Санкт-Петербурга) - работа по рефлексивному самоопределению по пирамиде Дилтса, индивидуально, с обсуждением в парах и группах. Это как раз к вопросу об уровне самосознания IT-шников - работа со специальными инструментами soft skill на уровне рядовых сотрудников. А я, заглянув на это выступление, соотнес для себя пирамиду Дилтса со схемой самоопределения Щедровицкого, о которой рассказывал прошлой весной на #sqadays и недавно на #teamleadconf, и которую мы будем обсуждать с Алексей Фёдоров на островке тестировщиков позднее. А еще эти активности показывают профит #itgm как точку кооперации сообществ - Ирина из IT HR, и ее позвали к аналитикам.

На #itgm был очень интересный трек SPB SQA Group. У него была сквозная тема - разделение труда в тестировании, и доклады и обсуждения нанизывались на эту тему. Я был только на последнем слоте, где мы вели обсуждение про схемы самоопределения, но открывая слот Алексей Фёдоров повторил для всех, включая вновь пришедших, содержание предыдущих серий - углубление специализаций, выделение отдельных, подвижность границ между тестировщиками и смежными специализациями - разработчиками, менеджерами, аналитиками. И потом как раз перешел к теме слота - схемам, которые помогают в этом самоопределиться.

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

И дальше мы пошли по схеме самоопределения, которую я уже рассказывал на #SQAdays, а тут мы по ней проходили конкретный кейс - предположим тестировщик хочет ввести практику тестирования требований и занять это место. Для начала - эту позицию как отдельную надо ввести в систему разделения труда. И показать, в чем ее ценность. И тут могут быть разные ситуации: может быть, что требования в проекте не тестируют и из-за этого есть проблемы, когда реализуют не то и не так. А может быть, это уже неявно делает аналитик - и тогда, если это захотел сделать тестировщик, надо понять самому и показать другим, что от такого перераспределения обязанностей будет выигрыш и для команды в целом, и для ее участников, в частности для аналитика. Дальше - розочка компетенций - тех, которые требуются, и тех, которые у тебя уже есть, и, из их сравнения - для тех компетенций, которые будут у тебя, занимающегося тестированием требований. Вернее, не у тебя, а у твоей марионетки. Потому что в этот момент ты раздваиваешься: ты по-прежнему продолжаешь занимать позицию тестировщика продукта и начинаешь занимать новую позицию тестировщика требований, и это делают две твоих разных марионетки, с разными компетенциями. И еще решить, как ты будешь компенсировать недостаток компетенций, который есть на входе, например, коммуникаций с заказчиком, или знание предметной области на бизнес-уровне. Чему-то требуется научиться на входе, а что-то можно прокачивать в процессе работы, в том числе - за счет постепенного изменения обязанностей. А где-то можно просто подвинуть границы позиции. А потом, если практика оказывается удачной, и ей следуют другие команды - то уникальная позиция в конкретном проекте превращается в роль, распространенную в компании. А ты сам, накапливая опыт, превращаешь разовую марионетку в свое амплуа. Последнее превращение фиксируется в резюме отдельной строкой опыта.

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

2018-03-15: FB напомнил про мои доклады на AgileDays-2016

Facebook напомнил про мои доклады двухлетней давности на конференции AgileDays. У меня было два доклада, по разным темам. Обе темы получили развитие, и я, пользуясь случаем, хочу о нем рассказать.

Два года назад выступал на #AgileDays Действуй опираясь на ценности (Максим Цепков на AgileDays-2016). Книга Лалу тогда только вышла, и я рассказывал о ней и о Спиральной динамике, и о соотнесении всего этого с Agile и его методами. Кстати, по Спиральной динамике это было уже второе выступление, первое было на AgileDays-2014 году (http://mtsepkov.org/SpiralDynamics-AgileDays), когда я только познакомился и оценил эту концепцию, понял ее силу. А в прошлом году тему продолжил (http://mtsepkov.org/AgileAgainstThirdWave), уже в контексте третьей промышленной революции.

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


А это - мой второй доклад на #AgileDays 2016 Agile - то что на самом деле нужно госзаказчикам (Максим Цепков на AgileDays-2016). И представленный там концепт развертывания проекта не от естественного для инженеров порядка разработки, основанного на связях системы, а от ценностей доставляемого результата, из которого выделяется MVP для внедрения, а внутри него - серия демо, ориентированного на конкретные целевые группы пользователей, я с тех пор рассказывал в других докладах и обучающих лекциях. По сути, это переворачивает привычное планирование проекта, потому что когда мы представили сценарий демо с точки зрения развертывания коммуникации с Заказчиком в хорошем темпе, оказывается, что разработать функционал для этого сценария - не так уж просто, и это - отдельная инженерная задача, разработчики, аналитики и PM ищут удовлетворительное решение.

Отмечу, что я не претендую на принципиальное открытие - многие идеи почерпнуты из тренинга Джефа Паттона для Product Owner, который я проходил в 2013 (http://mtsepkov.org/JeffPatton-PO), и где он рассказывал о планировании продукта от целевых групп пользователей которых мы хотим получить. Джефф вообще произвел на меня большое впечатление, а его фразу "Collaboration - это не разговоры и обсуждения. Это - совместная работа, и желательно - молча." - о часто цитирую. Ну а мы в CUSTIS адаптировали эти идеи для заказной разработки для наших крупных корпоративных заказчиков со многими особенностями.

В докладе было не только это, но и много другого о сотрудничестве с корпорациями. В несколько сжатом виде я в 2017 делился всем этим на ProfsoUX (http://mtsepkov.org/CorpCoop) - с тех пор, как в госпроектах начали обращать внимание и заказывать UI/UX перед многими небольшими компаниями актуальная задача - научиться взаимодействовать с миром иной культуры :)

Ну и в заключении - напоминаю, что через неделю состоится AgileDays. Можно участвовать лично, можно смотреть трансляцию.

2018-03-12: В эти выходные - на ITGM в Петербурге

В эти выходные - я снова в Петербурге на #ITGM. Мы с Лешей Федоровым будем глубже разбираться с ролями в проекте и с тем, кто их занимает - сам человек или его марионетка. Про актеров все понятно - они по Станиславскому в роль вживаются, чтобы хорошо ее сыграть. А на сколько это актуально в жизни? Сам концепт позаимствован у Петра Щедровицкого, я его рассказывал на #SQADays и #TeamLeadConf в докладе "Самоопределяйся технологично" (http://mtsepkov.org/SelfDet). Будем разбираться детальнее.

Полная программа IT Global Meetup, как всегда, очень интересна. Правда, как пишут организаторы "На данный момент регистрация закрыта, но вы можете узнать промокод у активистов сообщества. Также 16 марта в 09:00 будет открыта регистрация еще для 100 участников!". Так что попасть - можно.

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

2018-03-10: Пять лет моего знакомства с OMG Essence

Facebook напомнил - вот уже 5 лет, как я познакомился с OMG Essence из этого обзора Анатолий Левенчук (Anatoly Levenchuk) - обзор был несколько раньше, я прочитал с опозданием. Тогда же, в 2013 Ивар Якобсон приезжал на SECR и на его мастер-классе по Use Case 2,0 (мой отчет http://mtsepkov.org/UseCase-2-0) я увидел Essence в действии - как рабочую карту, на карту который кладутся методы, описываются их входы и выходы. При том, что сам инструмент Ивар не объяснял - вы же не объясняете ER-диаграммы, когда рисуете схемы данных, предполагается, что люди их знают или интуитивно поймут. И вот здесь потенциал интуитивного восприятия инструмента был довольно высокий, потому что мое знакомство было очень поверхностным.

Но мое освоение было не быстрым - я начал включать схему альф OMG Essence как карту для рассказа только в 2015 (в докладе Развитие управления проектами и критериев качества в ИТ http://mtsepkov.org/BigPicture-PM-IT), а жизненный цикл - только в 2016 (в докладе Ответственность за качество в разных ИТ-проектах: в чем она и как ее разделять http://mtsepkov.org/Responsibility4quality). И освоение продолжается - OMG Essence дают хорошие карты, на которые удобно раскладывать материал.

А осенью 2017 Ивар снова приезжал на SECR, и у него был доклад по использованию OMG Essence как средства для метаописания всех методов (видео и слайды доклада http://0x1.tv/20171021AL, а мой отзыв с обсуждениями http://mtsepkov.org/SECR-2017), а еще был однодневный матер-класс Ивара по управлению рисками проектов, на котором сначала был качественный обзор существующих методов, а затем - управление рисками через отслеживание состояний альф OMG Essence.

2018-03-07: Scrum, Kanban и разморозка бюрократий

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

Большим организациям свойственно бюрократизироваться, это в середине века исследовал Крозье (я об этом недавно писал), об этом же говорит жизненный цикл корпорации Адизеса, по которому корпорация уходит в аристократизм и бюрократию, а затем умирает. А Kanban — способен ее эволюционно оздоровить. Здесь уместно вспомнить схему из Спиральной динамики на рисунке справа. Она говорит о том, что эволюционные изменения возможны только если разрыв между состоянием организации и окружающим миром — не слишком велик, иначе необходима революция. Таким образом, эволюционное, а не революционное развитие наших крупных государственных организаций, откликающихся на внедрение Kanban, означает, что в целом наше государство в целом адекватно потребностям общества, способно к изменениям и развитию, и делает это. Что не может не радовать.

Собственно, я бы написал это неделю назад, но примерно тогда же на FB началась еще одна интересная дискуссия о том, что лучше для команды, переходящей на Agile — Scrum или Kanban. Там тема Kanban, его отличий от Scrum была достаточно активно затронута в обсуждением с Алексеем Пименовым, и я решил сначала завершить обсуждение там.

И здесь надо отметить, что для новой команды основное отличие Scrum от Kanban — как раз в эволюционном или революционном изменении не столько процессов, сколько системы ценностей. У любой организации есть две стороны, культура и процессы. Есть красивая схема-метафора кораблика, показывающая этот дуализм и придуманная Марком Розиным. И справа на схеме показана конструкция Agile в этой метафоре. Я тут процитирую один свой комментарий из того поста — но советую прочитать всю дискуссию, а может — и принять участие.

У этого вопроса есть два аспекта: ценности, процессы. С точки зрения процессов выбор зависит от того, есть ли в работе реальное квантование по поставке ценности потребителю — выпуск релизов. Scrum ориентирован на разработку, в которой ценности поставляются пакетами. Сейчас это, отчасти, снимается практикой continuous delivery, однако если новый функционал необходимо рекламировать, привлекать пользователей, то это все равно делается периодическими компаниями. А вот Kanban ориентирован на непрерывный поток задач, каждая из которых несет самостоятельную ценность и изолированно доставляется потребителю.

А вот с точки зрения трансформации культуры и принятия новых ценностей Scrum — гораздо лучше, потому что он резко перестраивает процесс, что влечет за собой осмысление и принятие людьми нового подхода к работе — или, наоборот, четкий провал в случае неприятия. Это происходит благодаря многочисленным встроенным встречам, которые значительно сфокусированы на ценностях, благодаря постановке целей на каждый спринт и другим подобным аспектам. И Scrum очень сложно внедрить без трансформации культуры. А Kanban с точки зрения ценностей — гораздо мягче, он вписывается в любую культурную среду, постепенно размораживая ее благодаря визуализации потока ценности, и благодаря старту постоянных улучшений. Поэтому его внедрение проходит мягче, но больше опасность, что трансформация будет ограниченной и затухнет. В IT это не слишком проявляется, потому что Kanban появился позже, чем Scrum, основные ценности и принципы Agile-манифеста уже были приняты сообществом, проявились успехи, и на повестку дня встал вопрос о мягкой трансформации больших компаний (ну и о работе с эксплуатацией и развитием систем, где нет четких релизов). Именно Kanban хорошо подходит для эволюционного размораживания и оздоровления больших бюрократизированных структур — он через доски workflow и побуждает задавать вопрос — несет ли конкретная работа ценность потребителю или нет, и кто вообще является потребителем для работ конкретного подразделения.

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

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

На этом - все.

2018-03-03: Прочитал лекцию в ВШЭ СПб

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

Кстати, именно с этим докладом у меня - аномально большое количество проблем. Основная запись первого доклада на эту тему на AgileDays-2016 "Действуй, опираясь на ценности" пропала, в результате сводили с использованием резервных каналов полгода. Осенью 2017 на PMonline отказалась запускаться трансляция слайдов с моего ноута, и Федор Афанасьев листал слайды для трансляции со своего... И вот опять :(

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

А презентацию - смотрите, кому интересно, http://mtsepkov.org/Agile-HSE-2018 Да, большинство слайдов там не новые, я уже рассказывал их на других докладах. Но лекция не является полным повторением. От лекции к лекции у меня самого происходит новое осознание, какие-то фрагменты развертываются, другие - свертываются. И сейчас я впервые попробовал положить культурные и процессные аспекты методов нового менеджмента на схему "Кораблик", которую придумал Марк Розин. Получилось интересно.

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

2018-03-01: В эти выходные - снова в Петербурге

В эти выходные (пятница-воскресенье) я снова в Петербурге. В субботу читаю гостевую лекцию в петербургском кампусе ВШЭ. Оказывается, уже несколько лет в Вышке действует система дополнительных курсов по выбору - майнор, с очень разнообразной тематикой. И, помимо курсов, проводятся гостевые лекции с приглашенными лекторами, вот я и попал в их число - с рассказом про новый менеджмент - Agile и бирюзовые организации. В пятницу и воскресенье относительно свободен, так что если у кого-то из моих питерских друзей есть идея встретиться - пишите.

2018-02-28: Интервью на Радиометрикс - про Agile, конечно

Дал интервью на Радиометрикс Наталии Беляковой о необходимостях и принципиальных возможностях и не-возможностях Agile. Видео на youtube https://youtu.be/vnRGRYIwCBM

2018-02-25: Выходные в Петербурге - WIAD и workshop по новому менеджменту

Эти выходные был в Петербурге.

→ продолжить чтение…

2018-02-21: Пойти работать в бирюзовой организации?

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

Из московских — интересен кейс «Доктор на работе», но это — небольшая IT-компания, и это подойдет не каждому. Что интересно — они не строили бирюзовую компанию, у них «само получилось». Есть интересный кейс самарской компании «Бизнес-гарант», они как раз целенаправленно перестраивали структуру управления под бирюзовую компанию. И при этом естественным образом убедились, что компания должна быть бирюзовой не по площади, а там, где это уместно и соответствует потребностям рынка. А там, где есть сложившиеся эффективно работающие подразделения, в которых сотрудники удовлетворены своей работой — форсировать развитие не нужно, и даже вредно. Но возможности, естественно, должны быть открыты. Еще есть ВкусВилл, он — работает на ценности здорового питания, это — основа сотрудничества и вовлечения персонала. Но при этом торговля — достаточно нормированная отрасль, и самоорганизация и возможность широкой автономной инициативы в значительной мере сосредоточена в офисе, а не на местах.

Еще интересны движения развития городов «Живые города» и «Центр прикладной урбанистики», которые представлены во многих городах России. Но они тоже не строили бирюзовое управление, у них оно получается. А еще они плохо укладываются в понятие «устроиться на работу» — в обоих смесь платных и бесплатных проектов, договариваешься об участии на конкретном проекте, это получается скорее фриланс, чем обычная работа. Будущее — именно за такой организацией работы, но не факт, что Вы сами к ней сейчас готовы.

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

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

И тут имеет смысл присмотреться не только к бирюзовым организациям, но и к кейсам Agile за пределами IT, но лучше не в крупном корпоративе, потому что там часто речь идет о ценностной перестройке компании. Информацию можно найти в группе «Agile вне IT». Еще имеет смысл смотреть кейсы, которыми делятся в рамках движений «Счастье в деятельности» (Филипп Гузенюк) и «Бизнес со смыслом» (Бехтеревы). Но при этом надо понимать, что многие из организаций только начинают путь перестройки, и потому непонятно, насколько по нему смогут продвинуться. А главное — оценивать, насколько Вам созвучны цели организации и ее способ принести пользу миру. Если Вы видите именно в этом свою самореализацию — хорошо, если нет — то зачем идти чужим путем?

Удачи всем в поиске работы, которой и процесс и результат будут приносить радость самореализации.

2018-02-18: Холакратия - почему критика часто не интересна

Обнаружил, что в конце прошлого года "Эксмо" выпустили книгу "Холакратия. Революционный подход в менеджменте". (Правда, у них там, видимо, по принципу "сапожник без сапог" отсутствует фото обложки) - https://eksmo.ru/book/kholakratiya-ITD827626/

Ну и, для поддержания кислотно-щелочного баланса - попалась мне тут занятная критическая статья "Холакратия – это тупик" ...

HolacracyBook.jpg

То, что Эксмо выпустили книгу - прекрасно. На Озоне, где ее можно купить, фото обложки есть и в посте оно оттуда.

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

Итак...

Давным давно, в 1986 году я смотрел Музыкальный ринг с группой Аквариум. Это было их первое выступление на телевидении, шла перестройка, люди пытались разобраться. И там выступал один товарищ из Ленинградского обкома, рассказывал о том, как он искренне пытался понять группу и причины ее популярности при полном отсутствии официальной поддержки - слушал записи, читал тексты, ходил на мелкие выступления - и ничего не понял. И это - не удивительно, другой mindset, другие ценности.

Так вот, товарищ эксперт смотрит на холакратию через свою призму традиционного управления - и ничего не понимает. И вот черты этого непонимания, и общий тон - знакомы еще по аналогичным статьям про Agile 10+ лет назад. И разбираться с этим по фактуре - нет смысла, потому что проблема в другом mindset, а он тут явно не сформулирован. Не, по фактуре проблемы тоже есть, это Алексей Ильичев (Alexey Ilyichev) выше написал, но вот смысла в этой дискуссии нет никакого. А на уровне mindset - каждый находится на своем уровне, и для роста должны быть внутренние причины, дискуссия в этом не убеждает ни разу.

Это, кстати, по опыту Agile и Scrum поняли авторы Холакратии. Поэтому они так жестко сформулировали свою конструкцию - для тех кто хочет попробовать, понять и принять в действии, по принципу Shu-Ha-Ri, в котором путь начинается с бездумного повторения за учителем. Зря, на мой взгляд, в современном мире такое воспроизводство ремесленного обучения не является эффективным. Хотя опыт Scrum подтверждает, что при опытном наставнике - работает. И экспериментов с отдельными практиками они не запрещают - просто жестко требуют не называть это Холакратией, надеясь не повторить те кейсы, когда Scrum сначала произвольно меняют, он не взлетает и дальше заявляют, что это не у них мозги кривые, а "Scrum не работает". В общем - их право на позицию.

В любом случае - нынешний этап - не пропаганда для завоевание мира, а сбора единомышленников, которые готовы пойти. А завоевание мира придет с подтвержденным успехом эффективности и распространением метода. Как с Agile для меня маркером успеха стал 2010-2012 года, когда IBM и Microsoft начали работать над переходом на Agile, ломая свою корпоративную культуру. При том, что оба были эффективными лидерами своих рынков. Причина проста: лучшие выпускники американских университетов перестали конкурировать за их оферы, уходя в стартапы со словами "вы, конечно, лидеры, но я выбираю свободу самореализации". И они поняли, что если так пойдет, то они останутся без лучших - и перестанут быть лидерами. И потому начали меняться. То же произойдет с бирюзовыми организациями и холакратией, и успех, естественно, будет не у нынешней первой версии - Scrum тоже прошел долгий путь эволюции до успеха, рядом появились другие методы, в частности Kanban. То же будет и здесь.

2018-02-11: TeamLead Conf - впечатляющий старт

Часть видео опубликована на Хабре. Полная публикация ожидается

Два дня, 08-09.02.2018 был на новой конференции Олега Бунина для тимлидов TeamLead Conf. 474 участника, и два трека очень хороших докладов. Очень высокий уровень по содержанию, по подготовке докладов, по компоновке программы. Я был на многих конференциях, достаточно много знаю в IT, так что ситуация, когда доклады в каждом слоте несут ценную для меня информацию, вызывают размышления - редкость. Тут было именно так. И, надеюсь, дальше будет не хуже. Потому что путь от разработчика к тимлиду - это актуальная тема. Я, кстати, специально не пишу "руководитель команды", потому что современный тимлид - он не классический руководитель. И вообще тимлиды - они очень разные, прежде всего потому, что компании - разные, у них очень разное распределение ответственности и обязанностей между сотрудниками, и, как следствие, очень разные тимлиды. И это разнообразие было в полной мере представлено на конференции.

Было очень круто! Спасибо докладчикам, спасибо вам, Олег Бунин, Александр Зиза, Роман Побочий, и всем остальным организаторам за работу над замечательной программой!

Я выступал с двумя докладами по совсем разным темам: Управление знаниями: какие документы нужны и что в них фиксировать и Как строить свой профессиональный путь - схемы самоопределения, презентации и аннотации можно посмотреть на страницах докладов. Приняли хорошо и было много обсуждений в кулуарах.

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

Началась конференция очень грамотной раскаткой докладов: Nikolay Krapivnyy из badoo рассказывал про рост компании от десятка до сотен, а за ним Георгий Могелашвили из Booking.com рассказывает про рост IT от 400 до 1500. Пост на FB.

Пост на FB Nikolay Krapivnyy из badoo. В целом очень интересный рассказ о внутреннем устройстве быстро развивающейся компании, выпускающий два релиза ежедневно, на сложном высоконагруженном продукте с достаточно сложной организацией компании. Спасибо!

Пост на FB Nikolay Krapivnyy из badoo. Характерный штрих по темпам современной разработки. Малое изменение за пару дней, а не несколько часов это проблема. В пару дней надо укладывать мини-проект для рекламной компании, а то окно возможностей закроется. Где в enterprise мыслят в таком темпе разработки?

Пост на FB Nikolay Krapivnyy из badoo. Рассматриваем процесс разработки с точки зрения теории массового обслуживания по обработке запросов на разработку и применяем их методы оптимизации. Тут я хочу отметить, что это будет работать для типовых запросов, но плохо работает для сложных. Результаты каждый может наблюдать, когда сталкивается с организацией массового обслуживания в поликлиниках и больницах. И это - системная проблема, потому что и IT-разработка и лечение - умственный труд, плохо поддающийся регламентации, а теория массового обслуживания - для организации труда, который можно регламентировать.

Пост на FB Георгий Могелашвили (Georgiy Mogelashvili) из Booking.com. Были команды с TeamLead и Product Owner, и они решили сделать команды без teamlead - потому что бурный рост, их не хватит. Эксперимент. Получилось. Георгий рассказывает, как разложились обязанности teamlead - решение конфликтов, фидбэк сотрудникам, выставление оценки. Реально интересно. Фидбэк, например, дают парами друг другу по графику. А оценки все ставят всем за круглым столом - и работает без конфликтов. Но все это - не само, bootcamp для команды и помощь на старте. В принципе, автономия сработала. Но возникают проблемы с ротацией сотрудников - сработавшиеся команды откатываются; ростом сотрудников без поддержки и engagement (они измеряли по google research perfect team). В результате teamlead вернулся, но в ограниченном объеме - он подключается только в ситуациях необходимой поддержки. Называется это servant leader. Основной фокус теперь - рост людей, но он отстраивает среду для этого, а не сам это делает. Так что в целом эксперимент говорит о том, что команда без Team Lead работает хуже, чем с ним, однако, автономность возможна, особенно в короткую, а помогать надо точечно.

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

Пост на FB Евгений Россинский Очень интересный рассказ. У них были команды, сформированные по технологиям (backend, web, разные мобилки), где каждый руководитель был экспертом в технологии, подбирал и выращивал специалистов. Но были проблемы с time to market. И они перешли на команды по value stream. Но при этом разработчики в каждой команде правят общий код на каждой платформы, и релизный цикл - тоже по платформам. Поэтому команды по платформам - восстановились. И сформировалась довольно сложная конструкция, которую Евгений и рассказывал со многими деталями и особенностями организации и коммуникаций.

Пост на FB Nina Scheglova из Lazada (Юго-Восточная Азия, технари в Москве, Въетнаме и Сингапуре) рассказывает про матрицу компетенций тимлида. Я тут подумал, что в IT, да и в другой технических отраслях часто смешивают soft skill, как коммуникационные, эмоциональные и другие компетенции, не связанные с профессиональной работой, с профессиональными компетенциями менеджеров. Ведь менеджер - это тоже профессия, и у нее есть свои hard skill.

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

В конце презентации - слайд со ссылками. Матрица тимлида https://goo.gl/zPw4GH еще есть тестировщика, программиста и дизайнера.

В комментариях к посту есть обсуждение содержания матрицы, а еще - обсуждение разницы soft skill и hard skill менеджера, которое я скопирую.

Ekaterina Semenova Hard skills менеджера мы целенаправленно не расписывали - они очень отличаются даже в рамках одной компании. Где-то много-много специфичных инструментов, а где-то - макросы и программирование в Экселе.
Максим Цепков Екатерина, мне кажется, Вы hard skill менеджера понимаете в IT-смысле - как владение определенными IT-инструментами. А я их понимаю по-другому, а именно, как как профессиональные скилы менеджера. Они ведь есть. То есть деление на soft skill и hard skill - не по тому, используются ли какие-то технические средства, а потому, что hard skill связаны с профессией (дисциплиной), а soft skill - от нее не зависят. Менеджер - это профессия, а менеджмент - дисциплина и у нее есть свой набор hard skill, которых учат, обучая менеджменту.
Ekaterina Semenova Теперь я поняла о чем Вы. С такой трактовкой понятий получается довольно интересно. С одной стороны у тимлида должны быть hard skills команды (программирование/ тестирование). И возможно Вы правы, когда разработчик переходит в тимлиды - его скилл, например, коммуникации становится hard skill'ом. Это можно будет обсудить отдельно.
Максим Цепков Там тонко. Возьмем аналитика. У него есть soft skill коммуникации и умение писать тексты, и есть hard skill проведения интервью (с фиксацией результата), в котором коммуникация и написание текстов - важная составная часть. Наверное, что-то аналогичное и здесь.
Ekaterina Semenova Ага. И прокачать можно видимо оба скилла

Пост на FB Alexey Kataev skyeng. В целом очень хороший доклад про распределенную команду - как нанимать, как организовать общение - чтобы в целом команда работала не просто не хуже, а лучше обычной работающей в офисе. И в докладе - евангелизм удаленной работы, которая лучше обычной.

Пост на FB Alexey Kataev skyeng. Вовлеченность обеспечивает общение, а не сидение в одной комнате. Поэтому hangout, камеры и много совместных встреч по работе и даже online-игры.

Пост на FB Alexey Kataev skyeng. Крутая практика работы с тех.долгом - рефакторинг митап. Разработчики вывешивают карточки о всех костылях, которые ему известны. Потому что это - распределенное знание. Дальше уже понятно - обсуждение, превращаем в таски и приоритизируем. А входной митап - круто.

Пост на FB Артур Орлов. 8 стратагем тимлида - клевый доклад о правильных паттернах поведения тимлида, стилизованных под китайские стратагемы. Много уроков - известно опытным, но для тех, кто тимлид недавно - они не очевидны. И подача очень классная.

  • Не стоит бросаться на все амбразуры самому - герой всегда остается один...
  • Когда задачи сообразны навыкам и компетенциям - не возникает обманутых ожиданий
  • Формируй культуру бесстрашных ошибок
  • Разработка и тестирование - одна команда, объединяй, а не разъединяй!

И так далее...

Артур выложил презентацию https://goo.gl/gF7o4q

Пост на FB Артур Орлов В ответе на вопросы о способах передаче знаний - много практик, а вот "написать документацию" - не звучит. Спрашиващий развивает тему и получает явный ответ: "документация без человека все равно не позволяет все понять, это уже пройденный этап".

В комментах к посту развернулась дискуссия по этому поводу. Мне кажется, она интересна, и я ее сюда скопирую.

Максим Шаломович На мой персональный взгляд - одно из самых спорных высказываний в докладе. Возможно, спрашивающий и докладчик сильно по-разному понимают документацию.
Максим Цепков Я думаю, скорее, у спрашивающего паттерн, что документировать - это передать знания. Есть такой. Но неверный, это весьма ограничено работает. И Артур это уже знает :)
Артур Орлов Согласен с тем, что высказывание спорное, постараюсь прояснить, свой ответ. Насколько я понял вопрос, он касался документирования знаний по собственно написанному коду, и вот в этом случае, на мой взгляд, она избыточна - код и так должен давать понять что и как он делает. Что касается документации того, что не имеет отражения в коде - то, конечно, она может быть полезной, если понятно, какие задачи она решает. Задокументированный стайлгайд и какие-то базовые принципы, например - очень полезная штука, хоть и не большая.
Максим Шаломович Ну хорошо, давайте конкретизируем. Документированные требования (например, несколько юзкейсов уровня всей системы, "черный ящик", и много юзкейсов уровня каких-нибудь подсистем/компонентов/элементов, "белый ящик")? Документированная архитектура хотя бы уровня структуры, ответственности элементов и интерфейсов взаимодействия? Документированные принципы разработки для отслеживания архитектурных решений a-la тех, что пропогандирует Саймон Браун (для устранения разрыва между моделями и кодом)? Что-то из этого по Вашему мнению и (или) опыту нужно для сохранения и передачи знаний?
Максим Цепков Я вмешаюсь в дискуссию... Тезис был не в том, что документация не нужна. Тезис был в том, что для сохранения знаний необходимо организовывать специальную коммуникацию в команде, когда знания передаются от человека к человеку, а документация сама по себе передачу знаний не обеспечивает. Если мы этот тезис принимаем (а я считаю его справедливым), то вопрос о документации становится вторичным, и ее количество и формы определяются участниками коммуникации - им что-то легче описать, чем запомнить и они это делают.
Артур Орлов Да, все именно так. Собственно, потому мне кажется работающим принцип, что лучшая документация создается тем человеком, которому она понадобилась, он получил ответы на свои вопросы в команде, зафиксировал. Тогда это действительно "работающая" документация )
Максим Шаломович Максим Цепков, я принимаю тезис, несмотря на то, что живу в мире заказной разработки по ГОСТ 34, и вопрос документации для меня, как правило, определяется контрактными обязательствами))) Мне интересно именно из опыта команд, ориентированных именно на сохранение и передачу знаний - какая документация в этом им реально помогала (перечисленные мной в предыдущем комментарии примеры). С одной стороны я понимаю, что архитектурная документация (от HLD до моделей уровня кода) в первую очередь нужна архитектору, поэтому ее с трудом можно назвать эффективным способом передачи знаний от архитектора/аналитика разработчикам (в этом плане совместная работа и шаринг знаний реально должны работать лучше). С другой стороны не могу не заметить, что в крупных распределенных (во всех смыслах) проектах ротация разработчиков и даже лидов довольно высокая. И передача знаний без какого-то персистентного ее хранения (к которому я не отношу голову разработчика :-)), наверное, невозможна. Понятно, код должен быть максимально понятным, но код - это продукт реализации, до которого есть много других шагов (анализ, дизайн - пусть и в максимально легковесном варианте, в рамках гибких ЖЦ). А что еще поможет?
Максим Цепков Я тоже живу в мире заказной разработки, и для части заказчиков мы делаем документацию по ГОСТ или их внутренней нормативке, так что мне это знакомо. Архитектурная документация точно нужна. И ротация разработчиков действительно довольно высокая. Но при этом опыт устная традиция в команде/группе/подразделений является одной из форм живого персистентного хранения. Об этом говорит мой практический опыт в IT, я наблюдаю это у многих заказчиков. Например, составление годовой отчетности ни в одном крупном банке не выполняется по регламентам, хотя они кое-где встречаются, но при этом традиция - живет. А дисциплина Управления знаниями. с которой я знаком, говорит, что это - правильно, что определение, какие знания делать явными и сохранять в артефактах, а какие держать на устной традиции - предмет управления.

Пост на FB Andrew Minkin Учат ответственности стажеров - делают внутренний сервис, через который люди в команде заказывают себе еду в офис :) И они видят, что такое проект в продакшн и зачем надо тестировать. И ущерб конкретный показывают - негатив. Да еще просрочки пробуют вешать на них кормление офиса...

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

В комментариях было обсуждение про эффективность подобной методики.

Эдуард Галиаскаров А практическое воплощение этой умной мысли есть?
Andrew Minkin Могу поделиться опытом как я делаю это в команде. Через несколько месяцев смогу поделиться как я это сделаю в учебном центре. Если конечно у меня получится :)
Эдуард Галиаскаров Интересно, конечно. Я пытался разыграть ситуацию: один студент пишет проектную документацию, другой ее реализует. При этом оценивается только проект, который соответствует проектной документации. В результате стал врагом номер один, похерителем гениев и талантов. Так что пока не решаюсь на повторные эксперименты :)
Игорь Бородихин Нужно измерять эффективность команды с применением этого метода и без, на короткой и длинной дистанции. Может внезапно получиться, что кроме издевательств над джунами (что само по себе неплохо в рамках их профессионального роста) для бизнеса никакого профита такая методика не приносит.
Максим Цепков Игорь, как раз рост джунов и был целью данной методики - потому что все это делали в рамках стажировки кандидатов в компанию. Эффективность стажировки компания меряет - количество и уровень сотрудников, которые пришли в компанию после стажировки против количества трудозатрат сотрудников компании на стажировку. И это - была не первая стажировка, которую компания проводит, так что они смотрят динамику, а эти методы как раз способ обеспечить эффективность для бизнеса.
К сожалению, в социальной сфере нельзя поставить чистый эксперимент: сдублировать команду, потом к одной копии применять некоторый метод обучения, а к другой - его не применять, или применить другой, и дальше сравнить результат. Поэтому такие предложения - не реализуемы.

Пост на FB Начало второго дня #teamleadconf Александр Киселев (Alexandr Kiselev) и Сергей Семенов (Sergey Semenov) - очень правильный доклад про метрики, измеряемые по коду и jira. Идея в индикативных метриках, разработанных под каждую проблему, которые привлекают внимание для разбора ситуации. В докладе - набор проблем и метрики для них. Индивидуальные проблемы - разработчики, которые почти не делают, или наоборот перерабатывают, или не дожимают задачи. Командные проблемы - недостаточно продумывание задачи, неравномерное знание о коде в команде, плохой onboard новых разработчиков, накопление технического долга. У них - стартап готового продукта, который это меряет. Но метрики - понятны, можно и самим мерить :)

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

Да, при разборе в большинстве ситуаций первый шаг - поговорить, понять причину и если действительно проблема - предъявить цифры. Часто цифр оказывается достаточно, люди просто не думают, что таковы потери (а метрики их показывают). Если не помогает - тогда надо думать.

Пост на FB Григорий Петров (Voximplant). Любопытный доклад, смесь физиологии мозга и работы со смыслами. Коммуникация, у менеджера проблема бизнеса из-за сроков разработки или бага, он приносит это сообщение, а разработчика опознает это как "менеджер ругается". Чтобы не было - надо формулировать сообщение так, чтобы оно не опознавалась как социальное взаимодействие двух людей, а как призыв выполнить социально принятый процесс. Например, переоценить сроки, или обсудить проблему. И много разных других приемчиков, включая использование и учет конотаций.

Пост на FB Егор Толстой Performance review в Avito. Масштаб - 1500 оцениваемых, около 10к оценок, в среднем каждого оценивает 9-11 человек. Системе - 3 квартала, один квартал - эксперименты, два квартала по полной. И при этом одна оценка - 10 минут у респондента, 4 часа в квартал. Понятно, что оцениваемый и его менеджер тратят больше. И отдельные метрики, которые показывают, что оценка работает как процесс, позволяет выявить системные сбои (вернее, дает гипотезы о них). Мне довольно интересно сопоставить с нашей, которой уже много лет, и которая развивается. Масштаб у нас сильно меньше. Но вот идея, что главное - не оценка, а развернутый отзыв - она есть и очень важна. Интересно, что в Авито все начинается с самооценки, а еще оцениваемый сам формирует массив профилей ожиданий от него (дает ссылки), по соответствию которым и надо оценивать. И они отдельно разбираются с ситуациями, когда респондент оценивает не по этому профилю. а по собственным ожиданиям. А еще в авито были интересные эксперименты по анонимности: начинали с полностью анонимной обратной связи, и поэтапно двигаются к тому, чтобы сделать ее открытой.

Пост на FB Круглый стол по выращиванию тимлидов. У Авито была практика "тимлид в кредит" - за знания. Отказались, потому что много людей выгорало: пытались продолжить писать код, но при этом еще работать как тимлид, не хватало сил. Теперь смотрят выявляют неформальных лидов, предлагают подтянуться и стать формальными.

Вообще круглый стол был большим и интересным, в телеграм-чате https://t.me/teamleadconf выложены фотки с досок (фиг долистаешь, но можно поиском "круглого стола"). Кстати, сам чат уже переименован в Боль Тимлида и обсуждение кейсов продолжается.

Пост на FB Оценка задач Дмитрий Симонов (Dmitriy V. Simonov) В докладе много про разные скрытые факторы, которые оценку увеличивают и приемы ее уменьшения. Например, devops - профи наладит инфраструктуры выкатки и автотестов, сократив многократно сроки этих этапов. Нет своих - ищите. А терки в команде могут увеличить работы многократно. Например, по поводу правильной расстановки скобок у if. Многое решается регламентами, например, code style. Или по взаимодействию другими командами - чтобы зафиксировать взаимные ожидания.

Пост на FB 1000 и 1 фидбэк Jane Goleva (Lamoda, в inhouse 300 IT-шников). Фидбэк надо Не принимать, но учитывать - это лишь одно мнение. И ты решаешь, насколько измениться. Учила фидбэку в клубе спикеров, где желающие готовились выступать на конференциях. Поэтому фидбэк - публичный и экологичный. Например, правило трех плюсов: не нашел их - молчи. А нашел - можешь высказаться. Но критика - в залоге, что можно улучшить, конструктив, а не негатив. И много-много других мыслей про фидбэк.

« новейшие ‹ 20 более новых старейшие »