Об "Водопад"

Наверное, не надо объяснять, что модель разработки проектов Waterfall (каскадную) не ругает только ленивый. Я пообщался с людьми, и узнал, что мало кто вообще понимает, какое отношение к ней имеет водопад и каскады. В качестве источника названия часто указывают статью, опубликованную У. У. Ройсом в 1970 году; при том, что сам Ройс в своем описании использовал итеративную (!) модель разработки. И какое отношение имеет последовательная разработка слева направо к метафоре водопада?

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

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

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

"..MDS – это внутренний яндексовый интерфейс облачного хранилища. Он более сложный, чем распространенный протокол S3, но он больше подходит для блочного устройства. [..] Он требует больше программирования. Программисты будут программировать, это даже хорошо, интересно"

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

*Управленческие этюды*

"На Хабре советуют программисту, который 3 месяца ничего не делал (модельная ситуация такая), в случае, если тимлид предъявляет за это претензии, выставить ему встречные – как так получилось, что у тебя сотрудник (я) 3 месяца ничего не делает, а ты не спохватился?"

Ответ от @SiliconBangalor:

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

🤡

*Планы*

С удивлением узнал, что менеджеры in the wild воспринимают планы (на неделю, на квартал) ровно как это в скраме пишут — "план это рекомендация, а не обязательство". Даже задумался, кто виноват, скрам или менеджеры…

Об hooman capital

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

Часто слышишь такой ответ: ты ничего не делаешь, а оно само работается. И это свидетельствует как раз о непонимании.  Другой частый ответ на вопрос: руководитель вдохновляет команду на работу. Реймонд Белбин  в середине 20 века обосновал, что между командным духом и успехом команды нет статистической корреляции. Потому что он наблюдал и команды, которые дружно шли к победе и тех, кто дружно шли к поражению. И даже команды, которые, вдрызг разругавшись, достигали победы. И успешные команды стабильных экстравертов (у которых было все в порядке с командным духом).
По факту, активностей у руководителя две:
- Ставить задачи - для этого надо декомпозировать цели в подцели и задачи
- Добиваться выполнения задач - как именно, никого не волнует, но инструментов для этого много.
Для этого он применяет самый важный инструмент управления - координация планов всех вовлеченных сторон. Сложность управления состоит еще и в том, что на уровне руководителя не бывает такой ситуации "нулевой результат": если результат не положительный, то он точно минусовой -- нуля не бывает. Капитал руководителя - это не сколько сплоченная команда, сплочение это инструмент, а желание работать, которое проявляют его сотрудники. Сплочение это способ повышения желания.  Ноухау, технологии, методологии - это все важно, но еще важнее эффективное вовлечение каждого члена команды. Напротив, если человек не хочет работать, то с этим мало что можно сделать. Чем умнее, тем более умные отговорки он будет вам говорить. С некоторыми ОЧЕНЬ умными разработчиками, которые не хотят работать, почти невозможно что-то сделать по этой причине.

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

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

Теперь, если проект провалится, или руководитель-идиот так решил "проучить" команду (всякое бывает), то позиция разработчиков такова: 90 и больше% ответственности за провал - на руководителе, предъявить команде нечего. Звучит логично, да.

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

А вы бы себе как на этот вопрос ответили?

"Представьте цех по выпуску холодильников. В нём 1 рабочий умеет делать звездолёты, остальные 10 — собачьи будки. Это и есть модель проекта разработки ПО, с ведущим разработчиком, миддлами, джуниорами и умением в технологии"

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

https://www.roscosmos.ru/29563/

Вопрос, на который непонятно как отвечать: что лучше?

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

ИЛИ

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

В архиве Роскосмоса нашлось прекрасное про rapid unscheduled disassembling. Я немного вырвал из контекста, но только лишь немного.

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

Об децимацию по-македонски по-микрософтовски

Недавно напомнили мне в беседе на тему управления, как в МС однажды ввели "палочную" систему в разработке. Ну, знаете, децимация и все на эту тему - типа того, что в команде априори есть слабые, поэтому по итогу отчетного периода надо обязательно показательно уволить 10% и 10% показательно премировать.

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

Я в свое время тоже был среди таких скорбных умом, и про себя насмехался. А вот сейчас переосмыслил: cost of opportunity.

1. В крупной компании всегда существуют какие-то аппаратные игры, внутренние ресурсы тратятся на "межвидовую" борьбу. И в предложенной схеме игры хотя бы понятны, понятны и правила. Все по известной схеме - не можешь победить интриги, так возглавь, и пусть корпоративные гладиаторы бьются на модельной арене.
2. А так ли плохо каждый год обновлять принудительно состав на 20%? Среднее время работы (абсолютно среднее с потолка) выходит 5 лет -- это плохо, что ли?
3. Правда ли уволят хороших? Серьезно? Ни один хороший менеджер не попрощается с классным инженером. Я даже больше скажу, у хорошего менеджера записная книжка полна надежных, производительных инженеров-перформеров, чтобы было кого дернуть себе в будущем - мало ли какой проект дадут и какую команду? А если менеджер уволил прекрасных инженеров, значит, не такой уж и умный менеджер, и в качестве результата на своем проекте рано или поздно получит закономерной провал.

Короче, схема как схема: наверное, бывают и лучше, но и эта не самая плохая.

Легко и даже с некоторой грустью представляю себе такие книги, но на современные темы для современных ИТ-пэтэушников: Git и его использование // Delivery невиданных скоростей // Service mesh: теория и практика.

Было бы куда больше пользы.

Сейчас из максимально полезного осталось разве что издательство BHV, в меру возможностей спасающее подрастающего технаря, а все остальное -- популярная механика уровня Men'sHealth

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

На другом конце находится подход "пиши/сокращай", который начинаешь везде подмечать, а спустя некоторое время — и раздражаться на него.

Писать надо от души.

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

Управление войск (сил) включает в себя такие мероприятия как:
* непрерывное добывание, сбор, обработку, изучение, обобщение, анализ, оценку и отображение данных обстановки;
* принятие решений;
* доведение задач до подчинённых;
* планирование боевых действий и других видов боевой деятельности, организацию и поддержание взаимодействия;
* организацию и проведение мероприятий по всем видам боевого и тылового обеспечения;
* руководство подготовкой подчинённых органов управления и войск к боевым действиям;
* организацию контроля и оказание помощи подчинённым штабам и войскам;
* непосредственное руководство действиями войск при выполнении ими боевых задач;
* ведение морально-психологической работы с личным составом
* и другие задачи

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

https://ru.m.wikipedia.org/wiki/%D0%A3%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B2%D0%BE%D0%B9%D1%81%D0%BA%D0%B0%D0%BC%D0%B8_(%D1%81%D0%B8%D0%BB%D0%B0%D0%BC%D0%B8)

Об противостояние "правила" VS "культура"

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

Мне кажется, ответ на этот вопрос все же есть: и то, и другое — все это традиция. Старая буддистская пословица гласит: "В добрые времена добрый муж укрепляет традицию, чтобы в худые времена традиция укрепила его". Укрепляйте ОБЕ.

Кубернетес для программиста

https://m.youtube.com/watch?v=t712aCafpeg

Об сверхурочную работу

Широко распространенная позиция по поводу переработок — НИ В КОЕМ СЛУЧАЕ, потому что это СНИЖАЕТ ПРОИЗВОДИТЕЛЬНОСТЬ. Обычно при этом ссылаются на "Роман об управлении проектами" Де Марко, где автор пишет — чем больше сверхурочной работы, чем ниже производительность. Кажется логичным, верно?

Так, да не так. Вы сами проверяли? Или читали?

Под сверхурочной работой автор там понимает работы свыше 60 (шестидесяти!) часов в неделю (то есть +20 дополнительных часов в неделю он не считает переработками), а спецэффекты снижения производительности становятся заметны после ПОЛУГОДА такой работы. Об этом же пишет и Брукс в его "Мифическом человеко-месяце".

Что ж нам с этого? Продолжайте филонить и рассказывать, как тяжело клепать круды, лентяи.

В пост о переработках забыл добавить, друзья, замечательную цитату из книги "Дао Toyota. 14 принципов" про основы экономического чуда Тойоты, которое потом стало основой бережливого производства и системы Kanban:

"Инженеры трудились от зари до зари, отменив все отпуска"

*Об биткойн*

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

Почему это происходит, думаю, объяснять особо не требуется

Мафия фейсбука давеча приобрела стартап Kustomer. Это такая чатоориентированная CRM на млрд $. Почему Kustomer, а не Chatfuel, скажем? А потому что среди клиентов - другие упакованные в т.ч. этими же инвесторами стартапы: Ring, Glovo, Birkenstock, Arrive. Одни стартапы помогают другим стартапам. Самоподдерживающаяся система, или другими словами - "тусовочка"