Байка для оруженосца-10. Военные маневры.

Июнь 18, 2016

Армигер маялся в кухне. Он пришел слишком рано, но ему было невмоготу. Наконец пришли Шляпник и Заяц. Пришли так же неожиданно рано.
— У тебя вид, как будто собираешься на первое свидание и не знаешь, какой букет выбрать.
— Примерно так. Мне завтра программистов собеседовать. А я ж тестировщик.
Шляпник вздохнул, открыл окно, сорвал с растущей рядом липы полною горсть липового цвета и занялся завариванием чая.
— Не умеешь проводить собеседования — не проводи их. У тебя что, времени как у дурака махорки? — Заяц, как всегда, был в своем репертуаре.
— Кстати, ты в курсе, что корреляция между умением проходить интервью и умением работать отсутствует? — поддержал Мартовского Безумный коллега.
— Э-э-э…
— Ладно. Завариваем чай и ждем. Не наливаем. Просто ждем.
Через пару минут дверь отворилась, и вошло около дюжины незнакомых Оруженосцу людей во главе с Соней.
— Привет, Храбрый Мыш. На рекорд идешь? Какой ты раз? Пятый? — спросил Шляпник у одного из вошедших.
— Пятый, пятый. Пока до минус двенадцати не дойду — не успокоюсь.
Мыш водрузил в центр стола огромную коробку и открыл ее. По кухне разнесся восхитительный запах свежеиспеченных плюшек с маком.
— Угощайтесь.
— Так, коллеги. Берем кружки, берем плюшки, пьем чай, — скомандовала Соня, — а Заяц тем временем все объяснит.
Когда все расселись за огромным столом и сделали по глотку, Заяц приступил к вводной части.
— Первое. Ваши резюме мы не читали. В нашей команде предпочитают добротную фантастику. Кэрролла, например. И да, у нас есть отдел кадрового учета, но нет отдела персонала. Так что ваши резюме вообще никто не читал.
Кто-то за столом закашлялся.
— Как нет отдела персонала?!
Заяц задумался.
— Как-то так. Надо у Чеширского спросить. Тебе надо, ты и спросишь. Продолжим. Собеседования у нас тоже нет. Ибо нефиг.
— Кстати, наличие и собеседования, и испытательного срока противоречит Трудовому Кодексу, — вставил реплику Шляпник.
— Для простоты мы просто берем на работу по краткосрочному контракту на две недели. По итогам двух недель делаем предложение. Или не делаем. Потом идет стандартное трудоустройство с трудовой и прочим. Иногда испытательный срок сокращается до недели.
— А как же три месяца?
— Зачем? — удивился Заяц. Если менеджер за две недели ничего не понял…
— То эти менеджеры работают в других командах, — прервал его Шляпник, — в отличных, замечательных командах. Но других. Не у Королевы.

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

— Несколько лет назад мы сохранили копию одного проекта. Все как полагается. Репозиторий, трекер, вики и прочая, и прочая.
— А репозиторий какой?
— Ты текст вакансии читал? Там все написано. Заметим, мы не требуем знания и опыта работы с этими средствами коллективной работы. Мы говорим, что в проекте придется работать с ними. Это не требования, как у некоторых, — и Заяц скосил глаз на соседний корпус. — Не требования, а условия работы. Так вот, на основании этого реального проекта у вас по четыре задачи трех разных типов. Все задачи делать не нужно, делайте шесть. Но нужно сделать минимум по одной задаче каждого типа. Исправить ошибку, сделать рефакторинг чужого кода и реализовать небольшую новую фичу. Рабочие места у вас оборудованы, но интернета нет. Телефон в бункере не ловит. Сделали задачи, залили в транк — свободны. Вечером пришлем ваш результат. На основании этого результата мы не принимаем. Эта оценка — ваш ориентир, на что вы можете рассчитывать. Мы берем и ведущих, и обычных, и начинающих. Стажеров тоже берем. Но мы рассчитываем, что ведущий программист наберет не более полудюжины минусов. И найти ведущего — большая редкость. Сделанная вами работа проходит юнит тесты, ревью кода. А потом начинается самое страшное. Ваш код начинают проверять тестировщики. И это самая точная оценка качества вашего кода.
— Вопросы есть? — скомандовала Соня. — Если нет, хватаем кружки, хватаем плюшки, идем в бункер.
Группу отправляющихся в бункер возглавила Соня, а в арьергарде пристроился Заяц.

— А ты тормозни, — придержал Оруженосца Мартовский. — В бункер успеешь.
Когда все вышли, Шляпник продолжил:
— Тебе, наверное, интересно, как идет оценка?
Оруженосец кивнул и налил новую чашку чая.
— Идеальная работа оценивается в ноль баллов. Это ровно шесть задач, с выдержанным стилем кодирования, прошедшие не только юнит тесты, но и тесты Сони. Такой результат встречается исключительно редко. Если точнее — встретился один раз за последние три года. Соня нашла, правда, одну ошибку, но сама признала, что для равновесия по Паретто это неизбежность.
— А кто это?
— К сожалению, он к нам не пошел. Живет в другом городе, а к нам просто зарулил на огонек. Продолжим. За каждый косяк идет от одного до дюжины минусов. Сделал меньше шести задач — минусы. Сделал больше — минусы. Вышел за час — минус. Не смог сделать по одной задаче каждого типа — минусы. Пренебрег кодестайлом — минусы. Использовал неправильную венгерскую нотацию — минус. Мы рассчитываем, что ведущий программист знает разницу между правильной и неправильной венгерской нотацией. Завалил юнит тесты — много минусов. Ошибку нашла Соня — меньше минусов. Не запустил юнит тесты после сборки — сразу дюжина минусов. Принципиально не уходит в фичебранч… За это надо бить ногами, но мы просто минусуем. При коммите не указал номер задачи из трекера — минусы. Не перевел задачу в «Open» при бранче — минус. Не перевел при мерже в транк — полная обойма из минусомета. Не оставил комментарий — ладно, есть номер задачи. Оставил бессмысленный комментарий — четыре минуса. За каждый бессмысленный комментарий. И т.д. Вот полный список.
И Шляпник протянул брошюру.
— Большая часть проверок автоматизирована.
— А если минусов больше шести, то не берем на работу?
— Почему не берем? Берем. Еще как берем. И даже если минусов больше сотни, тоже берем. И даже при полном бите минусов тоже берем. Просто будет не ведущий. Но, по-любому, это решается после двухнедельного испытательного срока.
— А почему Храброго Мыша не взяли?
— Мы бы его взяли, да он директор одной из софтверных компаний. К нам ходит из любви к искусству. Как сам говорит, что если бы платил за каждый сеанс по штуке баксов — его фирма все равно была бы в огромном плюсе. И он с удовольствием берет тех, кто к нам не пошел, но показал высокий результат. Набрал не более 128 минусов.

Помолчав, Шляпник добавил:
— У него сейчас великолепный результат. За полгода и четыре сеанса он поднял свой уровень очень сильно. Ну все, тронулись. Смени Зайца в бункере.

Байка для оруженосца - 9. Чтобы больше сделать, нужно меньше делать.

Июнь 6, 2016

Оруженосец шел в переговорку, как вдруг за дверью кухни услышал знакомые голоса
- А я тебе говорю, Load! - горячился Заяц.
- Сам знаю, что, Load! Но тут еще куча букв.

Армигер автоматически свернул в знакомую дверь. В конце концов, до совещания целых 20 минут, чашка отличного чая не повредит недавно назначенному руководителю проекта, и нужно понять, почему Заяц с Шляпником разгадывают его кроссворд в неурочное время. Сейчас самое начало рабочего дня, и до положенного времени чаепития еще очень далеко. А к Времени и Заяц, и Шляпник относились очень трепетно. Один раз они уже “пошутили”. И Оруженосец решительно толкнул дверь. На кухне собрались все программисты, и только программисты.
Читать дальше »

Байка для оруженосца - 0. Герои цикла.

Май 22, 2016

Дисклеймер. Это не мой текст. Такими этих героев увидела моя жена. У меня другое мнение, но я уважаю чужую точку зрения.

——————————-
Красная Королева (и нет, это не про “Обитель Зла”) - Руководитель команды. Потрясающая женщина. Страшная женщина. Железная женщина. Нет, кроме шуток. У нее стальные нервы, железная хватка, титановые яичники и чугунная задница. Поговаривают, что единственное, что у Королевы сделано не из металла - это сердце. Потому что оно каменное. Несмотря на все вышеперечисленное, обожает свою команду, и та отвечает ей тем же. Почти никто не может понять, как Королеве удалось собрать такую дрим-тим, ведь у большинства этих хмырей уважающий себя менеджер по работе с персоналом даже резюме смотреть не стал бы. А вот поди ж ты. Команда Королевы справляется с любыми заданиями, разгребает любые факапы, и если бы дело было в СССР, то вымпел “Передовики производства” поселился в их комнате навеки. Королева знает свое дело от и до и никогда не отказывается поделиться опытом с молодежью - чай, корона не свалится.
Все знают, что в фирме может смениться даже руководство, но Королева никуда не денется. А если захочет уйти, то с ней уйдет и вся команда. И их с радостью примут - хоть в НАСА, хоть в НАТО. На худой конец и “Майкрософт” сойдет.

Безумный Шляпник
- один из мастодонтов. На его кресле висит свитер, в котором, как утверждает сам Шляпник, он написал свою первую программу, на ЭВМ с ферритовыми сердечниками памяти. Этот свитер до чертиков пугает новичков - может, потому что он в неприятную красно-зеленую полоску, навевающую ассоциации с “Кошмаром на улице Вязов” и мальчиком, которого съела кровать. Впрочем, Шляпник и сам кого хочешь сожрет, без всякой кровати. Но если не испугаться свитера и спросить Шляпника о чем-нибудь по предмету, можно узнать кучу всего интересного.

Мартовский Заяц - тоже один из тех, кто переносил “Страну багровых туч” на восьмидюймовых дискетах и помнит времена, когда компьютеры были большими. Славен тем, что когда вся команда бьется над участком кода и не может сладить, лепит код из говна и палок молча приходит, садится и пишет код, больше похожий на бессмысленный набор символов, который при этом, что удивительно, работает как часы. Главное - не лезть в него и не пытаться ничего менять.

Чеширский Кот
- наглая, беспринципная, циничная сволочь с очень злым чувством юмора, граничащим с сарказмом. Иногда кажется, что он умеет быть сразу в нескольких местах одновременно. За рабочий день успевает пофлиртовать с девушками на ресепшене, попить чаю с тортиком с бухгалтерами и сыграть с гендиром пару раундов в “Need For Speed”. Однако когда злопыхатели пытаются уличить его в лености и невыполнении служебных обязанностей, выясняется, что у Чешира всегда все готово. Просто он умеет распоряжаться своим временем. Злые языки утверждают, что у него был роман с Королевой, но это совершенно не их дело.

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

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

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

Байка для оруженосца-7. Два вида списков задач.

Май 13, 2016

С самого начала рабочего дня Армигер скучал в чаепительной. За окном цвели яблони, а ему было нечего делать, и он составлял кроссворд на основании терминологии ISTQB. Кроме оруженосца в кухне был Чеширский, но он изучал какие-то документы. Но вот кухню омыла волна программистов во главе с Шляпником и Мартовским Зайцем.

- Хай.
- Привет.
- Доброе!
- Кому доброе, а кому и… - проворчал Оруженосец.
- Ничего. Придет время, и под твоей клавой навернется релиз-кандидат.

К чайникам выстроилась очередь. Программисты бурно обсуждали проблемы мержа.

В кухню вошел Черепах Квази. Шум стих.

- Представляете, захожу я сейчас в 42-ю, а там никого нет. Только Соня книгу читает, - сказал Квази, ни к кому конкретно не обращаясь.
- И что? - возмутился Шляпник. - Рекса Блэка надо читать.
- И больше там никого нет. Это все потому, что у вас тайм шитов нет.
- Ну да, а у вас есть. Только на наши релизы заказчик не ругается. Напомнить, что сказал ваш заказчик на ваш последний релиз?

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

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

На тушение пожара выдернули команду Королевы. В майские праздники. Вроде бы откат сделать не проблема. Но не проблема, только если инженеры соблюдают культуру разработки. Как говорится, тяжело править код за программистами, путающими бранч и транк. Да и релиз в пятницу вечером перед большими праздниками нарушал все мыслимые нормы безопасности. За два безумных дня команда Королевы много говорила о своих коллегах. Как подытожила Соня: “Если бы стены могли проявлять впитанные слова - в первый день они бы стали похожи на подъезд в Нижнем Тагиле, а на второй почернели бы полностью”.

- Но в чем-то он прав, - сказал Оруженосец. - Я с утра не слишком загружен.
Заяц и Шляпник переглянулись.
- Я сделаю сенчу. - Шляпник отправился к шкафам, а Заяц подсел за стол оруженосца.
- Сейчас я тебе объясню одну из ключевых концепций современной теории управления. Для начала разберем совершенно тривиальную производственную цепочку из одного рабочего центра. Проще уже некуда.
1654.PNG
- Разработчики работают по списку задач. И этот список может быть одного из двух типов. С недостатком задач или с избытком. Для первой линии техподдержки, админов и т.д. предпочтительным является список с недостачей. Для программистов, как правило, предпочтительным является список с избытком, но иногда применяют и список с недостачей. Например, если программист дежурит на техподдержке. Применение списка с недостачей означает, что разработчики обязаны часть времени простаивать. Обязаны! Если не простаивают - надо вызывать на ковер менеджера. Список с избытком означает, что часть задач обязана быть не сделана. Если делаются все задачи, опять же, нужно разбираться в проблемах управления. Представь, что мощность отдела программистов 100 единиц продукции в неделю. Для списка с недостачей рекомендуется, чтобы входящий поток заказов был в 70-80 единиц. Т.е. разработчики должны простаивать порядка 25% времени. Если используется список с избытком, то входящий поток должен быть отрегулирован на 130 - 200 единиц. Примерно вот так:
2654.PNG

Зеленые зоны - это хорошо настроенный поток. А красная - плохо.

- А если все-таки сделать сбалансированный поток?
- Если его попробовать сделать, то будет как у Квази. К счастью, сбалансированные цепочки встречаются редко.
- Сложно настроить?
- Нет, - подключился Кот, - настоящая причина того, что сбалансированные цепочки встречаются редко, намного более фундаментальна. Дело в том, что чем ближе ты к состоянию идеального баланса, тем ближе ты к банкротству.
- Хорошо, предположим. В дальнейшем я хотел бы увидеть модель, но сейчас я поверю опыту Чеширского Кота. - согласился Оруженосец. - И как настроено у нас?

- У нас список с избытком. Ты ведь знаешь, что часть задач закрывается триггером по истечении срока давности.
- Да, согласен. Но почему мы с Соней сегодня простаиваем?
- Потому что в производственной цепочке должно быть не более одного рабочего центра с избыточным списком задач. Этот рабочий центр называют ограничением системы. В нашей команде ограничением системы является группа программирования. И это правильно. Все остальные рабочие центры, такие как: менеджмент, тестирование, продажи, анализ - обязаны простаивать. Обязаны! Данный факт не согласуется с нашим представлением о мире и приводит к психологическому дискомфорту. Любой хороший список задач, что с недостачей, что с избытком, приводит к психологическому дискомфорту.

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

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

Тенденции в IT индустрии

Март 22, 2016

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

Дисклеймер. Все нижеописанное  - гипотезы.

Первая тенденция. «Автоматизация ради автоматизации». Автоматизация умственного труда не дает того же эффекта, что и автоматизация ручного труда. Внезапно.

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

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

Об этом уже писал Николас Дж. Карр в книге «Блеск и нищета информационных технологий. Почему ИТ не являются конкурентным преимуществом». А авторы статьи лишь подтверждают: часто автоматизация делается только ради автоматизации и вредит процессу.

Вторая тенденция: «Прощайте мигающие огоньки».

В 90-х годах даже люди, платившие деньги из своего кармана, покупали «автоматизацию» для «престижу». Но когда деньги перестали плыть бурным потоком, калькулятор все-таки понадобился, и в 2000-х бизнесмены уже начали считать деньги на автоматизацию. А а 2010-х уже и Государственному сектору понадобилось, чтобы ПО было рабочим. Появился спрос на функциональное ПО, способное поддерживать интеграцию с другими системами и при этом соответствующее минимальным требованиям безопасности. Электронный документооборот постепенно перестает быть разговорами об «инновационном завтра». Были поставлены сроки, в которые электронный документооборот должен стать обязательным. С наступлением этих сроков государственный заказчик понял, что старая модель общения с подрядчиками должна быть пересмотрена. То же самое с немалым удивлением обнаружили и подрядчики. «Вы представляете, какие сволочи эти заказчики? Они не только не купили новые сервера за 100500 денег, так еще и хотят, чтобы программа работала!?!?»

Третья тенденция. «Технологическая сингулярность» . Возрастание структурной сложности продуктов.

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

Четвертая тенденция: «Моя хата с краю». Резкое возрастание организационной сложности проекта.

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

Пятая тенденция: «Конец эпохи говнокода»
И последнее, что хотелось отметить в рамках данной статьи, – зримое падение компетентности программистов. Причин может быть много – политика последних 15 лет по отсечению опытных кадров по возрастному цензу, низкое качество современного обучения программистов, общая культура профессии и особенности менеджмента последних лет, но это тема отдельного разговора. Результат один: современные программисты совершают не только те же ошибки, которые совершали программисты 20 лет назад, но и те, которые старые программисты не совершили бы.

Разработчики стремительно утрачивают способности к анализу. Многие уже просто шарахаются от схемы БД в 200+ объектов, 500+ связей. Хм… дюжину лет назад с такой схемой легко работали тестировщики. Инженерам все сложнее становится читать длинные документы и статьи. Статьи в 3000+ знаков - это «ниасилил, многабукф». В качестве вишенки на торт абсурдная недавняя история. Разработчик не смог прочитать тикет с подробным описанием. В ходе ответов на вопросы разработчика, автор тикета просто ссылался на куски начального описания тикета. Т.е. разработчик не смог прочитать тикет ни с первого, ни со второго, ни с третьего раза.

PS. Напоминаем. Это лишь гипотезы. Вполне возможно, что сейчас трава по-прежнему зеленая.

be happy don’t worry

Защита от впихивыния невпихуемого

Март 21, 2016

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

Для предотвращения впихивания невпихуемого есть довольно простые правила.

1. Гениальная идея до того, как попасть к разработчику должна быть записана в трекер. Самим креативщиком.

Невыдуманная история. В одной из фирм маркетологам запретили чисто устную постановку задачи. Сначала трекер. Только потом можно рассказать устно. Поток гениальности снизился вдвое.

“Если ты не можешь записать идею на родном языке - возможно, тебе рано о ней рассказывать?”

2. Еще до фазы управления идея должна пройти минимальный анализ.

Иногда все очевидно и анализ не записывается. Пример: “Под нового заказчика ООО “Атлант” сделайте новый проект в Jira & пространство в Confluence”. Потому как в регламенте написано про НДА, которое реализуется через разграничение прав доступа к проектам Jira и пространствам Confluence. Но под “поток гениальности” анализ нужно зафиксировать.

3. Перед тем как разработчик хотя бы узнает о задаче порожденной гениальной идеей, идея должна пройти фазу управления.

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

Для случая непрерывной поставки и ограничения находящемся в производстве третье правило трансформируется в регламент со следующими пунктами:

1) Представитель заказчика утверждает порядок очереди работ. Т.е. основное управление осуществляется через “очередь” работ. Чем выше в списке (”ближе к кассе”), тем раньше задачу начнут делать. и вот этот самый порядок в очереди утверждается на встрече представителей заказчика и исполнителя. А если заказчик адекватный, то функции управления очередью можно отдать ему полностью и сэкономить на зарплате менеджера в группе разработки.

2) Задача прожившая в очереди работ более определенного времени (подбирается на основании экспериментальных данных) закрывается автоматически (скриптом). Другой вариант - должна быть не длиннее чем N задач. Например, если в неделю сыплется 10-20, а делается 5-10 задач. То у 50-й задачи нет шансов быть сделанной. За те 6-9 недель, которые нужны, чтобы до нее добраться прилетит еще 100-130 задач. И, если хотя бы половина из них будет поставлена перед 50-й, то…

3) Задачи управляемые по датам (изменение порядка исчисления НДС с 1.04.года) висят в очереди как можно дольше, пропуская вперед все задачи с немедленным экономическим эффектом. Смысл в том, что задачи, управляемые по датам приносят экономический эффект только после наступления этой даты. И для максимизации прибыли фирмы нужно откладывать их на последний момент. Но, естественно оставляя запас по времени под различные риски.

Тонкий момент. Для простоты, пусть у нас будет процесс, без проектов. В этом случае управление осуществляется регламентом. По пунктам:

* Менеджер не имеет права отдавать указания исполнителям. Исполнителями управляет регламент работ.

* Менеджер обязан управлять очередью. Не управление очередью со стороны менеджера должно рассматриваться как неисполнение прямых служебных обязанностей со всеми вытекающими последствиями.

* Менеджер (не обязательно этот же) может поменять регламент.

——–

Приложение. Дополнения, разъяснения и предупреждения.

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

Для справки. Фирма Хитачи несколько раз пыталась у себя производственную систему Тойота. У них хватало и опытных наставников из Тойота и денег и упорства. Но их производственная среда отличалась от среды Тойота. Итого: потеряв кучу денег они не смогли внедрить производственную систему Тойота и были вынуждены разработать другое прикладное решение под свою среду.

Вот небольшой список вопросов для определения, какое прикладное решение вам подойдет:

* Заказчик. Внутренний / внешний?

* Процесс или проект?

* Какова цена бага пропущенного в продакшен?

* Где находится ограничение системы?

* Сколько рабочих центров задействовано в работе?

* Взаимозаменяемы ли разработчики?

Это не все вопросы, но пока этого достаточно.

Для случая рассмотренного выше, ответы на вопросы будут следующие:

1. Заказчик внутренний. Упрощается взаимодействие. Не нужно «Закрывать контракты».

2. Процесс. Это означает, что задачи слабосвязаны и могут решаться независимо.

3. Цена бага незначительна по сравнению с преимуществом быстрого выпуска.

4. Ограничение системы находится в разработке. Пусть это сделали сознательно. Численность программистов сознательно поддерживается на таком уровне, чтобы гарантированно не быть в состоянии делать примерно половину задач. Сделано это, чтобы софт не превращался в ералаш (смотри «Слон живописец»).

5. Данный рабочий центр практически не взаимодействует с другими в потоке создания ценности. Т.е. когда заказчик размещает заказ, этот центр разработки все делает сам без привлечения программистов, тестировщиков, аналитиков из других отделов.

6. Разработчики взаимозаменяемы.

Литература по манипулированию людьми

Февраль 29, 2016

Некоторое время назад мне пришел любопытный запрос:

Добрый вечер, Сергей.
Я заметил, что вы не указали ни одной книги по риторике, софистике, эффективным комуникациям.
А у меня в последнее время складывается впечатление, что намного важнее “громко кричать”, нежели хорошо работать. В связи с этим вопрос к вам: можете посоветовать книгу, чтобы научиться “громко кричать” :)

Спасибо

Судя по всему, автор запроса прав. Но я бы выразился точнее. Не «эффективным коммуникациям», а «эффективным манипуляциям».

Отвечаю.
——————————————————–
Первая книга в списке, это «Психология влияния» Роберта Чалдини  Книга содержит описание очень сильных техник манипуляций и средств защиты от них. Что особенно приятно, каждая техника прошла исследование в соответствии с научным методом познания: наблюдение, гипотеза, эксперимент. Техник описано может и немного, но зато они расписаны подробно. Другие книги Чалдини я не читал, ничего не скажу. Но я планирую их прочитать.

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

Следующая сильно понравившаяся книги, это «Ложная слепота» Питера Уотса. Да, это фантастика. Но в отличии от фантаста Карнеги, пытавшегося писать научную литературу, это фантастика, которую писал ученый. В книге очень много информации об особенностях работы мозга. В этом смысле она служит хорошим дополнением к книге Чалдини. Кстати. Ближе к концу книги автор делает очень интересное предположение о том, что в перенасыщенном информации мире, преимущество в карьере имеет менеджер, не включающий мозг. И, похоже, это время уже наступило (смотри “технологическая сингулярность”).

Дополнительные книги:

  • “Buy-Ology: Увлекательное путешествие в мозг современного потребителя.” Мартин Линдстром
  • “Фрикономика.” Стивен Д. Левитт, Стивен Дж. Дабнер

Трассировка требований разных уровней

Февраль 26, 2016

Пояснение.
Материал готовился к докладу “Документ спецификации требований к ПО, а нужен ли он?” на аналитическом онлайн-марафоне “Проектный истории”. Материал в доклад “не вписался”. Оказался чересчур велик и сложен. Это нормально. Обычно на доклад я стараюсь набрать объем материала, с расчетом выбросить две трети. Тем не менее после доклада возник вопрос о трассировке требований разного уровня друг на друга. И тут такая удача - есть рабочий материал.

Дисклеймер.
1. Это рабочий, не конечный материал.
2. Очевидно, в нем есть ошибки. Один из тезисов моего доклада: “Если вы не нашли в формальном документе SRS ошибки, то зачем вы его писали?” Так что, если вы найдете ошибки в моей матрице трассировки, присылайте. Это будет значить, что я его не зря проделал работу.
3. Матрица не полна. Полная матрица в формат доклада никак не лезла. Там было бы очень много элементов. С полной диаграммой хорошо работать на мониторе 60″, с разрешением 4k. Но никак не через “смотровую щель” ноутбука.
4. Это пример, как такие матрицы можно строить. Просто иллюстрация подхода.

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

odhannedhiaea-odhaaiaaiee-aey-iao.jpg

Вариант использования как элемент планирования

Ноябрь 8, 2015

Use Case (вариант использования, ВИ, Прецедент, юскейс) это один из вариантов записи требований к системе. Дополнительную информацию о них можно узнать из статей:
•    Что такое Use Case и зачем они нужны?
•    Пример требований к системе
•    Байка для оруженосца-5. Использование вариантов использования.
•    Примеры вариантов использования (Usecase)
В отличие от многих других способов записи требований юскейсы обладают двумя приятными особенностями:

•    Существует множество формальных способов проверки реестра юскейсов на полноту.
•    Описан способ, как выделить уровни юскейсов.

Эти особенности позволяют легко создать достаточно полный реестр атомарных задач. Термин «Уровень» был предложен Алистером Коберном. Если очень грубо, то:

  • Юскейс «уровня моря» - это юскейс, при котором время взаимодействия с системой не превышает 20 минут и который, будучи выполнен многократно, приносит пользу. Часто юскейсы этого уровня составляют основу спецификации требований.
  • Юскейс «выше уровня моря» (змей, облако) - более высокоуровневый. Содержит несколько юскейсов уровнем ниже. Часто служит основой для переговоров с заказчиками.
  • «Ниже уровня моря» (рыба, моллюск) - составная часть «уровня моря». Часто используется для описания взаимодействия между системами в рамках одного юскейса уровня моря.

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

Рассмотрим несколько разных проектов.

Проект А.
Маленький проект. Несколько недель (месяцев) для одного программиста.
Спецификация требований на основе ВИ на него можно найти по ссылке: «Пример требований к системе»
Примечание. Сегодня я бы написал документ по-другому, но и такой вариант довольно сильно облегчит жизнь программисту.

Это несколько недель для одного программиста. Сколько именно, зависит от платформы.
1.    Java / C# + MSSQL – 6-12 недель
2.    Дельфи + SQLite – раза в два меньше
3.    FileMaker / MS Access / FoxPro / Clipper / Paradox – 3-10 дней

Если мы выбираем в качестве платформы C# + MSSQL, то для этого проекта удобно использовать юскейсы «уровня моря» в качестве уровня атомарной задачи. Реестр задач по этому проекту мог бы выглядеть следующим образом:

  • Работа с «Партнерами» - (юскейс над уровнем моря)
    • Создание необходимых структур в БД - (не юскейс)
    • Просмотр списка партнеров - (юскейс уровня моря)
    • Создание «Партнера» - (юскейс уровня моря)
    • Просмотр «Партнера» - (юскейс уровня моря)
    • Изменение «Партнера» - (юскейс уровня моря)
    • Удаление «Партнера» - (юскейс уровня моря)

Программисты на платформе C# + MSSQL, с которыми мы общались, утверждали, что делают в неделю 2-10 юскейсов вида «Просмотр, создание, изменение». То, что надо. Проводить дальнейшую декомпозицию нужно в очень редких случаях.

Примечание. При программировании на Paradox «Уровень моря» становится слишком мелок. Впрочем, с Paradox весь проект становится совсем крошечным, и для него формальный реестр задач необязателен.

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

  • Работа с Заказом
    • Просмотр заказа
      • Макет
      • Дизайн
      • Верстка
      • Программирование
    • Оформление заказа для авторизованного покупателя
    • Оформление заказа для неавторизованного покупателя
      • Страница «Вход»
        • Макет (не менее 6)
        • Дизайн макета 2
        • Дизайн макета 4
        • Дизайн макета 5
        • Верстка утвержденного макета
        • Программирование
      • Страница 2
      • Страница 3
      • Последняя страница
        • Макет
        • Передача заказа в программу логистики (юскейс)
        • Расчет бонусов (юскейс)

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

Измерение трудоемкости атомарной задачи

Ноябрь 7, 2015

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

aiciaay-ooa-ioaiee-odhoaiaieinoe.png
Как ее разбить?

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

  • 1-й период - 37 страниц
  • 2-й - 46
  • 3-й - 42
  • 4-й - 30
  • 5-й - 51

Это означает, что:

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

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

Несколько тонких моментов.

  1. Трудоемкость надо считать как N задач в M дней (800 задач в 400 дней), а не одна задача в среднем 2 часа. Ваш сотрудник ходит на совещания, читает почту, вынужден писать вам отчеты и т.д. Но это совершенно не важно. Заказчика волнует «Когда закончится проект?».
  2. Список сделанных атомарных задач является отличным отчетом. Другой отчет для контроля за работой сотрудника не нужен. Бонус: «Хотите поднять производительность сотрудника на 5-10%? Отмените таймшиты. Используйте реестр задач как отчет.»
  3. Обязательно возникнет вопрос: «Да, но есть страницы, которые верстались по неделе и более. Их надо разбить!». Нет, не надо. Пока отклонение в трехсигмовом пределе, не надо насиловать процесс. Будет только хуже. Смотри главы 4, 5, 6 книги «Пространство доктора Деминга».
  4. Пожалуй, самое главное. Вычисление уровня и создание реестра атомарных задач обязательно – обязательно! – должны предшествовать попыткам управлять задачами по «приоритетам», «дедлайнам» и т.д. Практически все пытаются сделать наоборот, что приводит к дичайшему хаосу в управлении. Вернее, к отсутствию управления.