Чего хотелось бы еще от werf, по небольшому опыту применения
* Сборка образов на машине разработчика (для тестирования и отладки инструкций) без лишних приседаний, включая работу под Win, как, собственно, можно делать с Dockerfile.
* Параллельная сборка независимых stages. Это сделало бы werf реально мощнее того, что может сейчас предложить многоконтейнерный Dockerfile.
Все, что изложено, смело можно перенести из мира программирования на любую другую отрасль. Данная «проблема» не специфична для программирования. Вспоминаю высказывание кого-то из великих конструкторов: «я проектирую какие-то гребанные мосты, вместо того, чтобы заниматься серьезными научными проектами!».
Как большинство «проблем», эта — в голове, а не в мире. Проблема — это противоречие. В частности, идеализированные картинки (например, про «высокое программирование»), порожденные из наших личных предпочтений, против реальности.
Во-первых, нужно принять, что мир сейчас, в данный момент, устроен так, как он устроен. «То, что есть — есть. То, чего нет — нет.» Отрицание реальности служит плохую службу.
Во-вторых, нужно увидеть свое место в мире в данный момент, и сразу станет понятно, почему к нам предъявляют именно такие требования, какие предъявляют (можно будет перестать этому удивляться и ожидать чего-то другого). Страус не выживет в Антарктиде, а пингвин — не выживет в Сахаре. В коротком времени подсистемы определяются условиями надсистем.
После чего нужно самоопределиться: или я остаюсь здесь (и тогда бессмысленно на что-то жаловаться — просто будь тут и живи на 100%), или я проявлю активность по отношению к своей проблеме — например, иду в другое место, более соответствующее моим амбициям и ценностям (может, и найдешь), или я говорю, что возьму и изменю это место! Не так много вариантов: остаться (подварианты: продолжать ныть или полюбить то, что есть), уйти, изменить.
В последнем случае самое глупое — пытаться изменить сразу весь мир (это опять романтизм и идеализации), нужно найти маленькую-премаленькую область твоего окружения и попробовать изменить ее. Скорее всего это не получится (или получится, но не совсем то), но в процессе человек что-то понимает и еще меняется сам. А может, и получится, и тогда это заряжает на кратно большие усилия к изменениям.
Становясь многократно в активную позицию, меняя места обитания, и обламываясь о полу-успешные попытки изменения, принимая реальность, и где-то чуть-чуть меняя её (чаще всего все равно не так, как нам бы хотелось), мы растем и живем.
И со временем наши старые проблемы начинают видеться совсем с другой стороны, казаться смешными, трансформироваться в просто обстоятельства.
Очень крутой шаг к созданию имиджа открытой компании. Браво! А как давно процесс change management'а для playbook'а у вас уже ведется? Кто и как принимает решения по внесению изменений? Как часто случается, что обсуждения заходят в тупик и в километры неконструктивных и не продвигающих вперед споров в issue discussion?
«Открывая организации будущего» и «Маверик» — две действительно прекрасные книжки, в которых описаны реально работающие примеры организаций, за которыми, по всей видимости — будущее. Я в это верю.
Но ничто так не удручает, как оголтелая примитивизация устройства этих организаций и превращение сложных принципов в звучные лозунги (мифы), совершенно не соответствующие действительности. По-моему это работает только во вред. На что это получается похоже? «Автомобиль — это такая телега без лошади! А раз без лошади, то, значит, без затрат на ее кормежку! То есть, ездим бесплатно!»
Самые классические мифы в данном случае — это «больше нет иерархий», «больше нет менеджеров», «нет должностных инструкций», и «команды сами принимают абсолютно любые решения». Это навскидку.
На самом деле иерархии никуда не делись, и не могут деться для организации крупнее 10-15 человек.
Потому что это единственный способ обуздать сложность.
Но отношения в иерархии несколько меняются.
Отношение «указание-выполнение» на некоторых уровнях иерархии и в некоторых областях меняется на отношение «делегированная ответственность.» Иерархия остается.И для успеха бирюзовой организации эта иерархия должна быть гораздо более четко очерченной и гарантированной.
На самом деле менеджеры никуда не делись, и не могут деться для организации крупнее 10-15 человек.
Но их деятельность несколько меняется.
Власть децентрализуется в бОльшей степени, чем обычно. Но многие права остаются иерархичны, например, права включение/исключение человека. К примеру, в холакратии это решает «не менеджер» под названием «лид линк», назначить которого быть лид линком может только… правильно, вышестоящий по иерархии лид линк :)
И решения команды тоже принимают — далеко не любые.
Прикольные примеры с инвестициями явно описаны как «строго контролируемые, в узких рамках». И так — естественно, все. Самоорганизация — всегда в жестко контролируемых рамках.
И должностные инструкции — обрели новые имена, формируются иначе — но тоже никуда не делись, и деться не могут, если деятельность достаточно сложна.
Команды в определенных границах определяют, как поделить работу, и после этого несут взятые на себя обязательства. Если их много — конечно, надо записать. В холакратии — _обязательно_ надо записать, на этот счет есть жесткий регламент в конституции и инструментальная поддержка. А при увольнении — все свои «не должностные инструкции» нужно передать сменщику :)
Увы, даже сами авторы — Лалу и Семлер, грешат тем, что пишут лозунгами, но при этом следом в деталях описывают, как на самом деле все устроено. А вот краткие дайджесты, и получасовые доклады на конференциях увы, часто ограничиваются лозунгами, из которых у читателя формируется совершенно некорректное представление. Это уже даже видно по предыдущим комментариям — «анархия», и т. п. высказывания. В этот момент начинается борьба лозунга, имеющего слабое отношение к реальным кейсам бирюзовых организаций, со здравым смыслом.
Так что читайте первоисточники и включайте мозг.
Кстати, все это же мы проходили лет 10 назад, когда появлялся agile. 10 страничек ритуалов, пробковая доска, — и «у вас все будет agile». Ага, щаз.
Если интересно — давайте разберем подробнее любой из упомянутых мною мифов — с текстом Семлера, Лалу, и конституции холократии в руках.
Кстати, буду рассказывать о том, как отличить настоящую цель от декларативной хотелки, на Analyst Days в Минске, 17 апреля. Потом могу дать видео доклада, кому интересно.
ФАКТ №4. Глобальная цель не связана с тактическими шагами… Есть ощущение, что пропасть между глобальной целью и тактическими шагами — это как раз свойство психотипа.
По-моему, есть гораздо более простое и реалистичное объяснение. У большинства людей просто нет глобальных целей. А написали они их, выдумав ровно в тот момент, когда вы их об этом попросили. Потому что своим вопросом вы пробудили представление о том, что «какие-то глобальные цели у меня точно должны быть». Но это не цель, а мечта, хотелка в стиле «не фигово было бы». Для существования такой хотелки тактика достижения не нужна :).
Эксперимент, опровергающий вашу трактовку, очень прост — достаточно найти в истории жизни человека моменты, когда у него действительно были достаточно длинные цели (например, переезд в другой город), которые были достигнуты. И спросить о том, как он к этому шел. И выяснится, что тогда связь между целью и шагами была и очень понятная. А значит, дело-то не в психотипе :)
* А чем у вас занимаются тестеры, если разработка начинается с написания автотестов?
* А кто у вас занимается сопровождением эксплуатируемой системы? У нее же есть пользователи и есть проблемы и непонятки, которые нужно оперативно решать, в т.ч. с привлечением разработчиков? Как это происходит?
* В ситуации, когда есть несколько важных вещей, которые нужно сделать, но все сделать не успеваете — КТО решает, куда бросить ресурсы?
* Какие проблемы известны в проекте? :) Технические и организационные? Ведь без проблем не бывает.
Хм… Удивительно мало тестов, на мой взгляд. И это — при отсутствии другой документации.
На что похожи эти тесты? Или есть несколько категорий тестов? Модульные? Приемочные?
Спасибо за рассказ, очень интересно!
И тоже хочется задать несколько вопросов.
1. Не бывает ли такого, что при внесении изменения возникает вопрос «Почему это было сделано именно так? Кто это просил? Кто и почему это так запрограммировал?». И никто из текущих людей этого не помнит (допустим, было написано давно, несколько лет назад). Как решаете такое?
2. Сколько в среднем разработчик и аналитик работает на этом проекте?
3. Как решаете архитектурные вопросы, если у людей в команде существенно разные мнения и нет формального архитектора? Есть неформальный? Или как-то все-таки быстро договариваетесь?
4. Сколько строк кода в итоге есть в системе и на каком языке? Сколько из них — тесты?
5. Сколько времени проходит от прихода в проект нового человека до его полноценного погружения? Ну, хоть примерно? Сколько времени длится испытательный срок?
6. Есть ли в системе СУБД и как от нее экранируетесь для тестирования? Как тестируется само взаимодействие с БД и ее структуры?
Пожелаю авторам проекта удачи. Но вот вопрос. Вы никогда не задумывались, зачем нужны агенты?
Я с работой хороших агентов чуть-чуть знаком.
Представьте, что агента нет, а есть только сервис с объявлениями от собственников.
Вы нашли 10 вариантов, вы их все обзвонили (некоторые — не сразу дозвонились), съездили по 10 адресам, иногда вас накололи со временем и вы час мерзли в подъезде, посмотрели 10 квартир. 5 из них оказались не соответствующими описанию, в ужасном состоянии. Еще три — оказались неудобны для вас по ряду параметров, о которых в объявлении не написано и по телефону не сказали. Одну сняли за час до вашего звонка о согласии. А последняя — оказалась с заниженной на 20% от реальной ценой. Вы потратили несколько дней времени, кучу нервов и ничего не нашли.
Часть нашего народу поселили в 6 корпусе, там было очень жарко. В некоторых номерах не было горячей воды, фенов. В первом корпусе — более менее нормально.
Столовая Покровского — просто праздник контрастов :) На шведском столе бутерброды с красной икрой а в пяти шагах — стоят ведерки для воды, капающей с потолка.
В общем, очень неоднозначные впечатления, мы очень удивились, когда узнали, что туда едет Microsoft.
Очень надеюсь, что организаторы заранее заедут в д/о покровское и посмотрят глазками на то, где предлагается жить участникам конференции. Мы выезжали туда на корпоративную сессию несколько недель назад и часть народа поселили в очень скверных условиях.
Бывает так, что ответ «шаблонный» в том смысле, что человек его просто повторил, где-то услышав, хотя это не то, что он на самом деле думает и чувствует. А бывает — что это действительно его ответ, хотя текстуально он тот же.
Дело, конечно, не в тексте ответа, а в отношении человека к этому ответу. Кто-то относится как в комиксе и «впихивает шаблон». А кто-то — серьезно. Даже по комментам это видно.
Оригинальный? Да чего же в нем оригинального?
Но если он честный — то это отличный ответ.
На самом деле честный ответ — почти всегда самый лучший.
Ответ «Я не смотрю так далеко в будущее, пока я просто ищу комфортную работу с хорошим коллективом, где смогу научиться чему-то новому» ничуть не хуже. Это тоже честно, и такие люди компании тоже могут быть нужны!
А вот всякие вымученные «Ну… мнэ… я, типа, наверное, буду мега-архитектором» идут точно не в плюс соискателю.
Наивно думать, что во всех HR-службах сидят конченные идиоты, которые не знают, что у человека спросить. Конечно, многие ичары повторяют эти вопросы просто как попугаи, не зная, как проинтерпретировать ответ, и, зачем, собственно, этот вопрос задавать. Но когда-то ведь эти вопросы появились, и у какого-то очень хорошего ичара их переняли остальные!
Давайте попробуем посмотреть на некоторые вопросы беспристрастно.
«Каким вы видите себя через 5 лет?»
О, да… Это все равно, что у слепого от рождения человека спросить, каким он последний раз видел солнце. Да никаким! Именно поэтому этот вопрос и вызывает такое раздражение у соискателей. Они вообще никогда не видели солнца, зачем об этом спрашивать?! Они даже вообразить не могут, что кто-то отвечает на этот вопрос вполне осмысленно и целеустремленно. Например, так: «Я рассчитываю поработать в вашей компании 3..4 года, после чего уйти в более крупную, международную компанию». Вот это — достойный ответ, и он, с большой вероятностью устроит ичара, потому что все равно средний срок работы в компании редко превышает три года. Зато он увидит перед собой человека, который не тупо плывет по течению, а четко представляет, чего он хочет.
Аналогично можно порассуждать и про остальные вопросы (кроме вопроса про люки, он про другое). Естественно, те соискатели, которые не в состоянии ничего осмысленного сказать про себя, свою жизнь и свои цели, начинают или пихать шаблонные ответы, или исходить сарказмом, как этот вот. Хорошему ичару тоже все становится понятно.
Хотя, конечно, смешно, смешно :)
Ради смеха добавлю еще один классный ответ на тупой вопрос в анкете:
"-- Расскажите о вашей мечте"
"-- Захватить мировое господство!"
Ну, в этом случае ничего тебе не мешает специально не выставлять define CONTRACTS_FULL, но тогда:
1. В отладочном режиме Contract.Assert все равно не будет отличаться
2. Ты используешь возможности инструмента (ReSharper'а) не по назначению — будь готов, что в следующей версии придется переучиваться.
* Сборка образов на машине разработчика (для тестирования и отладки инструкций) без лишних приседаний, включая работу под Win, как, собственно, можно делать с Dockerfile.
* Параллельная сборка независимых stages. Это сделало бы werf реально мощнее того, что может сейчас предложить многоконтейнерный Dockerfile.
Как большинство «проблем», эта — в голове, а не в мире. Проблема — это противоречие. В частности, идеализированные картинки (например, про «высокое программирование»), порожденные из наших личных предпочтений, против реальности.
Во-первых, нужно принять, что мир сейчас, в данный момент, устроен так, как он устроен. «То, что есть — есть. То, чего нет — нет.» Отрицание реальности служит плохую службу.
Во-вторых, нужно увидеть свое место в мире в данный момент, и сразу станет понятно, почему к нам предъявляют именно такие требования, какие предъявляют (можно будет перестать этому удивляться и ожидать чего-то другого). Страус не выживет в Антарктиде, а пингвин — не выживет в Сахаре. В коротком времени подсистемы определяются условиями надсистем.
После чего нужно самоопределиться: или я остаюсь здесь (и тогда бессмысленно на что-то жаловаться — просто будь тут и живи на 100%), или я проявлю активность по отношению к своей проблеме — например, иду в другое место, более соответствующее моим амбициям и ценностям (может, и найдешь), или я говорю, что возьму и изменю это место! Не так много вариантов: остаться (подварианты: продолжать ныть или полюбить то, что есть), уйти, изменить.
В последнем случае самое глупое — пытаться изменить сразу весь мир (это опять романтизм и идеализации), нужно найти маленькую-премаленькую область твоего окружения и попробовать изменить ее. Скорее всего это не получится (или получится, но не совсем то), но в процессе человек что-то понимает и еще меняется сам. А может, и получится, и тогда это заряжает на кратно большие усилия к изменениям.
Становясь многократно в активную позицию, меняя места обитания, и обламываясь о полу-успешные попытки изменения, принимая реальность, и где-то чуть-чуть меняя её (чаще всего все равно не так, как нам бы хотелось), мы растем и живем.
И со временем наши старые проблемы начинают видеться совсем с другой стороны, казаться смешными, трансформироваться в просто обстоятельства.
И это все вообще не о программировании.
А что за софтинка, если не секрет?
Но ничто так не удручает, как оголтелая примитивизация устройства этих организаций и превращение сложных принципов в звучные лозунги (мифы), совершенно не соответствующие действительности. По-моему это работает только во вред. На что это получается похоже? «Автомобиль — это такая телега без лошади! А раз без лошади, то, значит, без затрат на ее кормежку! То есть, ездим бесплатно!»
Самые классические мифы в данном случае — это «больше нет иерархий», «больше нет менеджеров», «нет должностных инструкций», и «команды сами принимают абсолютно любые решения». Это навскидку.
На самом деле иерархии никуда не делись, и не могут деться для организации крупнее 10-15 человек.
Потому что это единственный способ обуздать сложность.
Но отношения в иерархии несколько меняются.
Отношение «указание-выполнение» на некоторых уровнях иерархии и в некоторых областях меняется на отношение «делегированная ответственность.» Иерархия остается.И для успеха бирюзовой организации эта иерархия должна быть гораздо более четко очерченной и гарантированной.
На самом деле менеджеры никуда не делись, и не могут деться для организации крупнее 10-15 человек.
Но их деятельность несколько меняется.
Власть децентрализуется в бОльшей степени, чем обычно. Но многие права остаются иерархичны, например, права включение/исключение человека. К примеру, в холакратии это решает «не менеджер» под названием «лид линк», назначить которого быть лид линком может только… правильно, вышестоящий по иерархии лид линк :)
И решения команды тоже принимают — далеко не любые.
Прикольные примеры с инвестициями явно описаны как «строго контролируемые, в узких рамках». И так — естественно, все. Самоорганизация — всегда в жестко контролируемых рамках.
И должностные инструкции — обрели новые имена, формируются иначе — но тоже никуда не делись, и деться не могут, если деятельность достаточно сложна.
Команды в определенных границах определяют, как поделить работу, и после этого несут взятые на себя обязательства. Если их много — конечно, надо записать. В холакратии — _обязательно_ надо записать, на этот счет есть жесткий регламент в конституции и инструментальная поддержка. А при увольнении — все свои «не должностные инструкции» нужно передать сменщику :)
Увы, даже сами авторы — Лалу и Семлер, грешат тем, что пишут лозунгами, но при этом следом в деталях описывают, как на самом деле все устроено. А вот краткие дайджесты, и получасовые доклады на конференциях увы, часто ограничиваются лозунгами, из которых у читателя формируется совершенно некорректное представление. Это уже даже видно по предыдущим комментариям — «анархия», и т. п. высказывания. В этот момент начинается борьба лозунга, имеющего слабое отношение к реальным кейсам бирюзовых организаций, со здравым смыслом.
Так что читайте первоисточники и включайте мозг.
Кстати, все это же мы проходили лет 10 назад, когда появлялся agile. 10 страничек ритуалов, пробковая доска, — и «у вас все будет agile». Ага, щаз.
Если интересно — давайте разберем подробнее любой из упомянутых мною мифов — с текстом Семлера, Лалу, и конституции холократии в руках.
vimeo.com/125908124
По-моему, есть гораздо более простое и реалистичное объяснение. У большинства людей просто нет глобальных целей. А написали они их, выдумав ровно в тот момент, когда вы их об этом попросили. Потому что своим вопросом вы пробудили представление о том, что «какие-то глобальные цели у меня точно должны быть». Но это не цель, а мечта, хотелка в стиле «не фигово было бы». Для существования такой хотелки тактика достижения не нужна :).
Эксперимент, опровергающий вашу трактовку, очень прост — достаточно найти в истории жизни человека моменты, когда у него действительно были достаточно длинные цели (например, переезд в другой город), которые были достигнуты. И спросить о том, как он к этому шел. И выяснится, что тогда связь между целью и шагами была и очень понятная. А значит, дело-то не в психотипе :)
* А чем у вас занимаются тестеры, если разработка начинается с написания автотестов?
* А кто у вас занимается сопровождением эксплуатируемой системы? У нее же есть пользователи и есть проблемы и непонятки, которые нужно оперативно решать, в т.ч. с привлечением разработчиков? Как это происходит?
* В ситуации, когда есть несколько важных вещей, которые нужно сделать, но все сделать не успеваете — КТО решает, куда бросить ресурсы?
* Какие проблемы известны в проекте? :) Технические и организационные? Ведь без проблем не бывает.
На что похожи эти тесты? Или есть несколько категорий тестов? Модульные? Приемочные?
Я имел в виду, есть ли уже какая-то статистика сколько времени человек работает до увольнения? Или пока только нанимаете?
И тоже хочется задать несколько вопросов.
1. Не бывает ли такого, что при внесении изменения возникает вопрос «Почему это было сделано именно так? Кто это просил? Кто и почему это так запрограммировал?». И никто из текущих людей этого не помнит (допустим, было написано давно, несколько лет назад). Как решаете такое?
2. Сколько в среднем разработчик и аналитик работает на этом проекте?
3. Как решаете архитектурные вопросы, если у людей в команде существенно разные мнения и нет формального архитектора? Есть неформальный? Или как-то все-таки быстро договариваетесь?
4. Сколько строк кода в итоге есть в системе и на каком языке? Сколько из них — тесты?
5. Сколько времени проходит от прихода в проект нового человека до его полноценного погружения? Ну, хоть примерно? Сколько времени длится испытательный срок?
6. Есть ли в системе СУБД и как от нее экранируетесь для тестирования? Как тестируется само взаимодействие с БД и ее структуры?
Я с работой хороших агентов чуть-чуть знаком.
Представьте, что агента нет, а есть только сервис с объявлениями от собственников.
Вы нашли 10 вариантов, вы их все обзвонили (некоторые — не сразу дозвонились), съездили по 10 адресам, иногда вас накололи со временем и вы час мерзли в подъезде, посмотрели 10 квартир. 5 из них оказались не соответствующими описанию, в ужасном состоянии. Еще три — оказались неудобны для вас по ряду параметров, о которых в объявлении не написано и по телефону не сказали. Одну сняли за час до вашего звонка о согласии. А последняя — оказалась с заниженной на 20% от реальной ценой. Вы потратили несколько дней времени, кучу нервов и ничего не нашли.
Может, пора позвонить агенту? :)
Так что и правда, хорошее совпадение, только не с LOST, а с более ранними культурными элементами.
Столовая Покровского — просто праздник контрастов :) На шведском столе бутерброды с красной икрой а в пяти шагах — стоят ведерки для воды, капающей с потолка.
В общем, очень неоднозначные впечатления, мы очень удивились, когда узнали, что туда едет Microsoft.
Бывает так, что ответ «шаблонный» в том смысле, что человек его просто повторил, где-то услышав, хотя это не то, что он на самом деле думает и чувствует. А бывает — что это действительно его ответ, хотя текстуально он тот же.
Дело, конечно, не в тексте ответа, а в отношении человека к этому ответу. Кто-то относится как в комиксе и «впихивает шаблон». А кто-то — серьезно. Даже по комментам это видно.
Но если он честный — то это отличный ответ.
На самом деле честный ответ — почти всегда самый лучший.
Ответ «Я не смотрю так далеко в будущее, пока я просто ищу комфортную работу с хорошим коллективом, где смогу научиться чему-то новому» ничуть не хуже. Это тоже честно, и такие люди компании тоже могут быть нужны!
А вот всякие вымученные «Ну… мнэ… я, типа, наверное, буду мега-архитектором» идут точно не в плюс соискателю.
Давайте попробуем посмотреть на некоторые вопросы беспристрастно.
«Каким вы видите себя через 5 лет?»
О, да… Это все равно, что у слепого от рождения человека спросить, каким он последний раз видел солнце. Да никаким! Именно поэтому этот вопрос и вызывает такое раздражение у соискателей. Они вообще никогда не видели солнца, зачем об этом спрашивать?! Они даже вообразить не могут, что кто-то отвечает на этот вопрос вполне осмысленно и целеустремленно. Например, так: «Я рассчитываю поработать в вашей компании 3..4 года, после чего уйти в более крупную, международную компанию». Вот это — достойный ответ, и он, с большой вероятностью устроит ичара, потому что все равно средний срок работы в компании редко превышает три года. Зато он увидит перед собой человека, который не тупо плывет по течению, а четко представляет, чего он хочет.
Аналогично можно порассуждать и про остальные вопросы (кроме вопроса про люки, он про другое). Естественно, те соискатели, которые не в состоянии ничего осмысленного сказать про себя, свою жизнь и свои цели, начинают или пихать шаблонные ответы, или исходить сарказмом, как этот вот. Хорошему ичару тоже все становится понятно.
Хотя, конечно, смешно, смешно :)
Ради смеха добавлю еще один классный ответ на тупой вопрос в анкете:
"-- Расскажите о вашей мечте"
"-- Захватить мировое господство!"
1. В отладочном режиме Contract.Assert все равно не будет отличаться
2. Ты используешь возможности инструмента (ReSharper'а) не по назначению — будь готов, что в следующей версии придется переучиваться.