Мир изменился. А человеческая психология осталась в прошлом веке.

Раньше мы жили в мире материи и энергии, а сейчас живем в мире информации.

"… -Мы займемся арифметикой… У вас в кармане два яблока… Буратино хитро подмигнул: – Врете, ни одного… – Я говорю, – терпеливо повторила девочка, – предположим, что у вас в кармане два яблока. Некто взял у вас одно яблоко. Сколько у вас осталось яблок?.. "

Правильный ответ, конечно, — одно яблоко.

Рассмотрим другую ситуацию.

"… -Мы займемся арифметикой… У вас в голове два знания… Буратино хитро подмигнул: – Врете, ни одного… – Я говорю, – терпеливо повторила девочка, – предположим, что у вас в голове два знания. Некто взял у вас одно знание. Сколько у вас осталось знаний?.. "

А вот в этом случае, правильный ответ – два знания.

Потому что в информационном мире не действует закон сохранения: «ежели где убудет несколько материи, то умножится в другом месте…». Поскольку информация не материя, и не энергия. В отличие от производства, например, автомобилей, еще один экземпляр информации для производителя ничего не стоит.

Выступление Германа Оскаровича Грефа не осталось незамеченным не только среди политического и экономического истеблишмента, но и получило резонанс в ИТ-сообществе. Еще бы. «Agile, cloud-based, deep machine learning, artificial intelligence», – и все эти базворды не из уст айти-гика, а слова государственного деятеля, президента и председателя правления Сбербанка России. Думаю, что Герман Оскарович, конечно, не сам писал тезисы айтишной части своего выступления, а, как обычно, помогали эму в этом айти-советники.

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

Цитата: «В прошлом году мы сделали 27 000 изменений платформы. Для сравнения — 5 лет назад мы делали 600-800 изменений. В этом году мы сделаем 41 000 изменений. Если посмотреть на банки – мы в шоколаде, все в порядке. Если посмотреть на вот этих ребят всех – Amazon, Google и так далее, то Amazon делает 10 000 изменений своей платформы в день. 10 000 в день и 40 000 в год это несопоставимые вещи. Time to market – часы, и time to market – месяцы, это неконкурентоспособная история».

Вопрос: О чем свидетельствует число изменений платформы в единицу времени?

Ответ: Ни о чем, кроме производительности программистов.

Гипотеза: Численность сотрудников компании Amazon, примерно 100000 человек. Поскольку бизнес компании — продажа товаров и услуги через Интернет, а не производство ПО, то айтишники в ней — обслуга, и, полагаю, что они составляют не более 5% от общей численности. Итого, где-то, 5000 человек. Из них программистов, примерно, четверть, то есть, 1250 человек. Остальные менеджеры, аналитики, тестировщики и прочие админы. Считаем производительность.

Среднее количество изменений, переданных программистом в тестирование за рабочий день, = 10 000 изменений в день / 1 250 программистов = 8 изменений в день.

И это очень крутой конкурентный результат.

Как-то в Московском отделении PMI, учитывая мой специфический опыт, попросили рассказать об особенностях менеджмента в СССР. А опыт у меня такой. 20 лет разработки ПО в ЦУПе и еще столько же в коммерческих компаниях.

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

Постараюсь быть краток, поэтому буду говорить только о главном.

Люди

Рональд Рейган говорил: «Окружите себя самыми лучшими людьми, которых вы только сможете найти, передайте им в руки власть и не мешайте им».

Вот главные качества, которые отличают лучших сотрудников:

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

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

И вот, почему.

В моей картине мира способность человека достигать успехов в жизни определяется формулой

Е = IQ * EQ^2,

где E – жизненная энергия человека, IQ – коэффициент его интеллекта, а EQ – коэффициент его эмоционального интеллекта.

Чек-листы – это эффективный инструмент контроля. Они сводят к минимуму возможность упущения важной информации и снижают вероятность совершения ошибок типа «не знал, забыл, закрутился».

Стив Макконнелл в своей книге «Остаться в живых. Руководство для менеджеров программных проектов» приводит тест проекта на выживание. Этот чек-лист из 33-х пунктов, который должен иметь под рукой каждый менеджер, если он хочет привести проект к успеху. Процитирую этот тест с небольшими уточнениями, основанными на личном опыте.

Каждый из 33 пунктов оценивается от 0 до 3:
0 – даже не слышали об этом;
1 – слышали, но пока не применяем;
2 – применяется частично;
3 – применяется в полной мере.

Если какой-то пункт не применим, в силу особенности вашего проекта, ставим оценку равную единице. Итоговая оценка — сумма баллов, по всем пунктам.

Ну, что, берем в руки калькулятор и обследуем ваш проект?

Как-то на ФБ среди френдов образовалась дискуссия о том, сколько уровней управления должно быть для обеспечения эффективной деятельности организации. Вспомнил доклад Арнольда (не терминатора, а математика), представленный почти 20 лет назад, на семинаре при Президентском совете РФ. В докладе был сделан достаточно неожиданный вывод.

«Многоступенчатое управление, описываемое нашей моделью при n > 3, неустойчиво. Двухступенчатое управление приводит к периодическим колебаниям, но не вызывает катастрофического нарастания колебаний, происходящего при трех- и более ступенчатом управлении. Настоящую устойчивость обеспечивает только одноступенчатое управление, при котором управляющее лицо более заинтересовано в интересах дела, чем в поощрении со стороны начальства».

Как такое возможно, если в организации тысячи сотрудников?

А что-то про SEMAT тут никто еще не написал? Исправляем.

Предисловие

Знакомлюсь с SEMAT – Software Engineering Method and Theory. Показалось разумным. Размышляю о возможности применения в своих проектах. Анализирую риски. Хотелось бы привлечь Хабраразум.

1. От автора

1.1. Это ответы ИТ-менеджера своему боссу на его часовой матерный монолог в стиле — «Когда мне понадобится твое мнение, я тебе его скажу!»

1.2. Эти ответы позволят ИТ-боссу или тому, кто еще только собирается им стать, открыть для себя много нового.

1.3. Новости будут черные. Плохие, очень плохие и еще хуже. Они даже, могут вызвать когнитивный диссонанс (деформацию мозга). Так что, если у тебя (мы ведь уже перешли на ты?) нежная психическая организация, то может нафиг оно тебе и не надо, и не стоит дальше читать.

1.4. Эти ответы так же не претендуют на истину, правоту или любую другую абсолютную правду. Это просто другой взгляд на ту же самую разработку ПО, который, как я скромно надеюсь, позволит тебе увидеть проблемы ИТ-отрасли бинокулярным зрением. Сделает их более объемными и, следовательно, откроет их тебе с другой и, скорее всего, неожиданной для тебя, стороны.

1.5. Автор, таки, претендует на определенный опыт в ИТ, поскольку пашет в этом бизнесе уже 35 лет, причем 25 из них является ИТ-менеджером.

1.6. Поэтому буду говорить не о том, что видел и слышал, а о том, от чего остались шрамы на шкуре и на языке, как верно заметил старик Адизес.

Случалось ли вам наблюдать, как руководитель проекта с самого его начала постоянно занимается пожаротушением, полностью погружен в борьбу с неотложными проблемами, темп поступления которых превышает скорость их решения. Все задачи, которые получает команда проекта, имеют наивысший приоритет и срочность: «Это надо было сделать еще вчера!» Трудовой героизм. Постоянные сверхурочные. Субботники. Авралы. Обучение, анализ, планирование, проектирование, тестирование, рефакторинг – «это все потом!».

Знакомо?

«Хорошо управляемое предприятие — это спокойное место. Зато «фабрика, отличающаяся «кипучей» деятельностью и «трудовым героизмом» работников, который бросается в глаза любому посетителю, является на самом деле плохо управляемой», писал управленческий авторитет Питер Фердинанд Друкер.

Проблема большинства проектов разработки ПО заключается не в том, что люди мало трудятся, а в том, что они делают не ту работу, которую нужно делать. Хороший менеджер должен руководствоваться фундаментальным принципом наименьшего действия и, следовательно, быть ленивым. И у него все получится. Почему?

Введение

Жизнь сложилась так, что я уже почти сорок лет разрабатываю ПО. Как и многие, тоже мечтал о софтверном конвейере, фабрике и индустриальной разработке и даже участвовал в попытках их воплощения в жизнь. Реальность эти мечты убила и заставила признать, что программирование отличается от индустриального производства и в нем методы управления Макдональдса не работают.

Как-то знакомый преподаватель английского языка рассказал, что вчера был на вечеринке и услышал анекдот:

— Ложась спать программист ставит рядом на столик 2 стакана.
— Один с водой — если захочет пить, второй пустой — если не захочет.

Смеялись только программисты, а остальные и он, в том числе, анекдот не поняли. Пришлось сильно постараться, чтобы объяснить гуманитарию, что в этом анекдоте смешного.

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

Disclaimer. Сейчас программистов много. Хороших и разных. Я буду писать про хороших. И то, не про всех, а про большую часть из тех, с кем имел честь вместе разрабатывать ПО.

Лично меня жизнь убедила, что люди это капитал. Особенно в нашей отрасли все зависит от людей. Если кто-то сомневается в этом, то очень рекомендую книгу шведов Кьелла А. Нордстрема, Йонаса Риддерстрале, «Бизнес в стиле фанк. Капитал пляшет под дудку таланта». Книга не новая, но, имхо, очень доходчиво разъясняет, почему Маркс, Ленин и Мао Дзэдун были правы в современном мире это именно так.

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

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

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

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

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

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

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

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

UPD: В ходе обсуждения коллективный разум родил, вполне себе, логичное завершение поста

Во время проекта двое бойцов развелись, один слег с нервным расстройством.

Вася, устав воевать с ветряными мельницами, воскликнул: «Карету мне, карету!» и обновил резюме на hh.

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

Почему ты не можешь дать точную оценку трудоемкости разработки?
Почему ты не можешь завершить все работы в два раза быстрее?

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

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

Предисловие

Есть распространенное мнение: «если бы строители строили дома так же, как программисты пишут программу — первый залетевший дятел разрушил бы цивилизацию». С подачи индийского гуру-программиста Мурали Кришна Чимутури (Murali Krishna Chemuturi), Интернет настойчиво приписывает авторство этой цитаты Джеральду Вайнбергу (Gerald Weinberg), хотя на личном сайте Джеральда она не ищется. Скорее всего, человек, который первый заговорил о психологии в программировании, к этому высказыванию не имеет никакого отношения. И вот, почему.

Это изречение – пример демагогического приемчика. Здесь пропущена главная посылка: разработка ПО это то же самое, что и строительство домов. Эта посылка, по умолчанию, подразумевается как достоверный факт, который не требует доказательства. Применение этого приемчика заставляет неискушенного читателя делать ложный вывод о том, что у программистов, в отличие от строителей, руки растут не из нужного места.

Материальное производство (обработка объектов физического мира) насчитывает десятки тысяч лет истории. На этом пути был накоплен колоссальный объем знаний естественных наук: математики, физики, химии, географии, геологии, биологии и проч.

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

«Когда человек не знает, к какой пристани он держит путь, для него ни один ветер не будет попутным». (С) Сенека, Луций Анней

Предисловие

Как-то один из топов уважаемой компании, которая занимается продуктовой разработкой ПО, пригласил меня, как эксперта, чтобы я оценил качество нового продукта. Я внимательно просмотрел и прослушал презентацию. Видно было, что коллеги очень старались и работали по 10-12 часов, чтобы продукт выглядел на высшем уровне. После чего меня спросили: «хороший получился продукт или нет?» Я поблагодарил за представленную презентацию, но попросил ответить на свой последний вопрос: «А какие процессы, и с какой целью вы собираетесь автоматизировать с помощью этого инструмента?» Вопрос почему-то вызвал замешательство у докладчиков. После небольшой паузы, топ, который, видимо, был идеологом нового продукта, ответил: «Был бы инструмент хороший, а какие процессы с его помощь автоматизировать мы найдем!» Мне пришлось сказать, что оценить продукт я не смогу. Не зная бизнес-целей, невозможно понять степень их достижения.

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

Для иллюстрации используем проект «Экспедиция за сокровищами Флинта»

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

Ставим задачу

Кого ищем? Ищем эффективных бойцов. Известно, что эффективность программистов со схожим опытом может отличаться в 10 раз (Ф. Брукс) или даже в 27 раз (Р. Гласс). Сразу, оговорюсь, эффективность это не только количество трупов врагов реализованных требований к ПО на единицу трудозатрат, но и умение результативно взаимодействовать с окружающими. Это важно, потому что по моим наблюдениям 50% проектных человеко-часов тратится на коммуникации. У нас это называется «синхронизация ментальных моделей».

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


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

Мифы – это попытки осмысления картины окружающего мира, присущие первобытной культуре.

Материальное производство (обработка объектов физического мира) насчитывает десятки тысяч лет истории. Оно прошло путь от каменных пещер до современных небоскребов, от сигнальных костров до мобильной связи, от навигации по звездам до навигации по космическим спутникам. На этом пути был накоплен колоссальный объем знаний естественных наук: математики, физики, химии, географии, геологии, биологии и проч.

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

За короткую историю в отрасли сложилось большое количество мифов, суеверий и религиозных заблуждения. Эти мифы, суеверия и заблуждения, порой очень похожи на правду. Они получили широкое распространение и пагубно влияют на руководителей, которые никогда сами профессионально не разрабатывали ПО. Следствием этого является применение неадекватных методов и подходов в управлении программистами, что гарантированно приводит проект к провалу.

Вот наиболее распространенные мифы и факты, которые их опровергают.

Я не владелец бизнеса. И не исполнительный директор. Я, как и все программисты, наемный работник. Поэтому решение о повышении зарплаты своим подчиненным принимаю не я. Но я даю рекомендации. И к ним прислушиваются или нет.

Рассуждаю я примерно так.

Сколько же надо платить программисту? Как правило, рыночная «вилка» вознаграждения для конкретной квалификации известна и составляет от X до 1.5*X. Можно рискнуть и платить по нижней планке — X. Однако, возможность получать в 1.5 раза больше за ту же работу скорее всего перевесит все остальные мотивы, которые удерживают бойца в моей команде. Ситуация усугубляется еще и тем, что агрессивные «охотники за головами» делают разрыв в вилке еще больше, чтобы побыстрее перекупить квалифицированные кадры. Надо ли платить по верхней планке, тем более, если она сильно завышена? А, может быть, следует платить еще больше?

Заранее, приношу свои извинения, за занудность и излишнюю детальность нижеследующего изложения в стиле — «как для домохозяек». Я много раз пытался объяснять свое видение подхода к решению этого вопроса людям, которые должны были принимать решение о повышении оклада, но они не всегда меня понимали. Или, может, просто, не хотели?

Каждый год мы обучаем под свои проекты и набираем в команду студентов. Хантим, конечно, не всех. «Мы на работу ходим, а нам деньги плотют» — это точно не к нам. За «звездами» тоже не охотимся. Ищем в первую очередь тех, кто хочет расти, развиваться, становиться «звездой», а мы можем им в этом помочь.

Одна из проблем нашего высшего образования в том, что в вузах учат много чему, и алгоритмам, и языкам программирования, и ООП, и даже паттернам проектирования. Но я еще ни разу не встречал, чтобы в вузах учили работать работу. Лабораторки не в счет. Спихнул – и забыл! Возможно, просто не везло.

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

Итак, про семь навыков…