Ноябрь, 2023 | Владимир Бычко об управлении проектами

Владимир Бычко об управлении проектами

пиэм разъясняет, предостерегает, рекомендует

Месяц: Ноябрь, 2023

Мысли из Линкадина — 15

Изображение с unsplash.com, автор bruce mars

Об эскалациях

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

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

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

* * *

О тренере и пивоте

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

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

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

* * *

О неочевидных фичах

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

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

Устройство молнии с блокировкой.

* * *

О роскоши оффлайна

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

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

— Чувак, то есть тебя от того, чтобы вылететь на встречку и впилиться в фуру, останавливала только нарисованная двойная сплошная?
— Да.

* * *

О файловых менеджерах

Одним из первых приложений, с которым я столкнулся, впервые встретив IBM PC, был нортон коммандер. Особо привыкнуть к нему не получилось, потому что достаточно быстро на этот компьютер была установлена Windows 95.

Когда файловых операций немного, хватает возможностей проводника, но когда более опытные друзья наделили меня дистрибутивами Windows Commander и FAR, я прям возрадовался, особенно первому. Если его как следует настроить, файловые операции начинают делаться сильно быстрее, чем в Проводнике. С тех пор Windows, а позднее Total Commander сопровождают все мои виндовые компы. FAR не прижился. Да, у него возможностей ещё больше (особенно с плагинами), но отпугивает консольный интерфейс. Наверное, людям, сильно прикипевшим к Нортону, с Фаром подружиться проще.

А на маке файловый менеджер оказался не нужен. Finder удобен. Когда нужно что-то экстраординарное, задействую Commander One Pro.

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

Norton Commander со сториз.

* * *

О рандоме

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

Почему-то с какой-то версии Яндекс.Музыка в Хроме стала подлагивать, время от времени прерываясь на долю секунды, что раздражает. Чтобы не раздражаться, я поставил Файрфокс и стал запускать музыку там. Чтобы не переключаться на него каждый раз, использую для старта/паузы и переключения треков аппаратные клавиши ноутбука.

Так вот, если смотреть в основном Хроме какое-нибудь видео и, поставив его на паузу, нажать на аппаратную кнопку «плей», НИКАКИМ образом невозможно предсказать, чьё воспроизведение возобновится, этого видео или фоновой Яндекс.Музыки, это подлинный рандом каждый раз.

Можно сделать этот рандом ещё сложнее, запустив в фоне видео с VLC.

vlc

* * *

Об экспертности

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

* * *

О системе в именах файлов

Много раз убеждался, что если в файловом хранилище не придерживаться некой системы именования папок и файлов, уже через пару лет (и смене двух поколений сотрудников) найти что-либо в нём будет невозможно.

* * *

Об ознакомлении

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

* * *

О времени и приоритетах

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

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

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

* * *

О трекинге

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

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

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

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

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

Короче, не заставляйте пиэмов трекаться.

* * *

О помощи коллегам

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

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

* * *

О сборнике ссылок

Однажды, когда я передавал проект, меня попросили сделать отдельный документ со всей относящейся к проекту инфой — подробным статусом и ссылками на все-все проектные артефакты. Результат мне так понравился, что я стал делать по всем своим проектам такие документы, даже если корпоративные стандарты этого не требовали.

Делаю это в Эверноте, но этот выбор никому не навязываю (не так давно писал 13 причин, почему он мне не нравится), можно в любом другом заметочнике или вообще, гуглодоках. Особенно важно, когда у вас несколько проектов, между которыми нужно переключаться. Ну и да, передавать другому пиэму будет легко, минутное дело.

* * *

О лукизме

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

Руководители с вычурной внешностью.

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

* * *

Об обкатке изменений

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

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

Короче, обкатывайте изменения на «старичках», у «новичков» и так жопа в мыле.

* * *

О равновесиях

Представьте, что вы ректор университета и вам правительство предлагает два варианта. Либо оно даёт грант на миллиард вам, либо два миллиарда, но соседнему университету. И сообщает, что ректору соседей будут предложены такие же условия.

Ясный перец, что вы выберете миллиард себе, а соседний ректор заберёт миллиард себе. В итоге каждый получит по миллиарду.

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

За подобные рассуждения Джон Нэш получил в итоге Нобеля и про него сняли фильм с Расселом Кроу.

В том числе для этого нужны умеющие договариваться менеджеры.

* * *

О книгах

Позабавил факт. Калифорнийский книжный клуб Джерри Фиалка начал читать роман Джойса «Поминки по Финнегану» в 1995 году и закончил спустя 28 лет — в ноябре 2023.

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

Джойс писал этот роман 16 лет, а они читали 28.

В итоге пришли к выводу, что книга им не понравилась.

Калифорнийский книжный клуб Джерри Фиалка.

* * *

О лавстори

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

* * *

Особое мнение о пресейлах

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

На мой взгляд, это подмена этапа планирования. Она совершенно бессмысленна по двум причинам:

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

Большей глупостью является только попытка поставить в план конкретных людей.

Что касается работы с рисками, считаю целесообразным на этапе пресейла определить, является проект среднерискованным или высокорискованным и тупо применить 20 или 30 % ко всем затратам. Выделять отдельные риски можно, но только самые ключевые, картина рисков на реальном проекте тоже изменится. Такой подход, кроме прочего, даёт пространство для манёвра, если окажется, что оценка слишком высокая — можно будет пройтись по каждой задаче с архитектором и аналитиком и вместо процентов проставить сумму рисков вручную, так можно сильно ужать оценку.

Скажите «нет» простыням на восемь вкладок на этапе пресейла. Максимально верхнеуровневой оценки достаточно, клиенту нужен порядок цифр, проект будет стоить 5 млн., 10 или 100, этой цифры и пары-тройки ключевых рисков достаточно для принятия решения. Разбиение по крупным модулям тоже нужно. Всё остальное, в любом случае, придётся пересчитать на этапе планирования проекта. Это называется процессами первичной и точной оценки.

* * *

О мыслительном процессе

Объём, в котором сотрудники должны думать — вопрос дискуссионный. На первой серьёзной работе в разработке я столкнулся с командой, в которой аналитики расписывали все аспекты доработок досконально, из-за чего разработчики натурально превратились в кодеров, делающих ровно то, что написано в ТЗ, даже если на самом деле, решение ошибочно.

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

Один чудак написал мне в обратной связи в качестве недостатка: «Приходит с вопросами и проблемами, не приносит своих решений». Это правильное поведение с командой, только так её можно сделать самостоятельной и не погрязнуть в микроменеджменте. И да, переспросить: «А сам-то как думаешь?» на вопрос подчинённого — тоже норма. Если он предлагает чушь, аккуратно скорректировать. Но поощрять самостоятельное мышление, позволяя принимать большое количество решений на низовых уровнях управленческой пирамиды.

* * *

Об интерфейсах

Играю же в «Битву замков» на мобилке, давно уже, лет девять. И разрабы в очередной раз сделали козу — мой клиент вдруг стал на английском без возможности переключения языка. Играть на английском невесело, я в эту игру захожу деградировать, а не подтягивать навыки. Удалил, нашёл в гугл плей русскую версию, скачал. Раза с четвёртого аккаунт подтянулся, выдохнул.

И через некоторое время обнаружил, что фигурки героев в режиме боя не отображаются. Точнее, вместо них схематичные чёрные рыцари:

Битва замков.

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

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

К чему это я. Разрабы бы не переломились при запуске игры отобразить попап: «Без скачивания дополнительных ресурсов игра не работает должным образом. Но у вас выключен вайфай. Можно мы скачаем 500 мегабайт ресурсов через мобильный интернет?», вместо того, чтобы отобразить незаметную иконку (там этих иконок как грязи, большинство бесполезные) и терпеливо ждать.

* * *

Об оценке

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

* * *

О стереотипных высказываниях

Мои школьные учителя очень любили в отношении двоечников, неспособных ответить на вопрос или решить задачу, употреблять две фразы: «Картина Репина „Приплыли“» и «дошёл до ручки». На самом деле, смысл у этих культурных объектов совершенно другой и к деградации отношения не имеет.

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

Картина Репина «Приплыли»


UPD. Оказывается, картины Репина «Приплыли» не существует. Это картина Соловьева Льва Григорьевича (1839-1919). Картина называется «Монахи» («Не туда заехали»), просто она висела рядом с выставкой Репина. За комментарий спасибо Максиму Королю.

Насчёт ручки. Дело в том, что на Руси был такой стритфуд как калач с ручкой из теста. За ручку его держали во время поедания, а потом эту ручку выбрасывали, считая грязной. Дойти до ручки — обеднеть настолько, что начать есть ручки от калачей. Это не о деградации, а о бедности.

Ну и бонусом «растекаться мыслью по древу». В оригинальном произведении была не мысль, а мысь — белка. Целиком это звучало как:



«Вещий Боян,
Если песнь кому сотворить хотел,
Растекался мысью по древу.
Серым волком по земле,
Сизым орлом под облаками»

Это не о демагогии, это о том, чтобы рассмотреть явление с разных точек зрения.

* * *

О важности адаптации практик к современным реалиям

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

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

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

* * *

О продуктах

Худшее, что компания может сделать с продуктовой точки зрения — выпустить качественный, но ненужный продукт. Или нужный, но слишком поздно.

* * *

О помойках

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

Когда я впервые этот самый интернет попробовал, был очень удивлён. Я ввёл ya.ru на компе на кафедре где-то в 2003 году и открылся яндекс. Попробовал вбивать туда поисковые запросы и переходить по ссылкам. И оказалось, что интернет не такой уж помойный, там можно найти «Звёздный десант» Хайнлайна (правда, на пузатом мониторе читать это было невозможно), разные форумы и сайты с приколами, на которых можно поржать.

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

В общем, тут не помойка, тут нормально.

Вы оффлайн.

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

Изображение с unsplash.com, автор Tommaso Curre

Вводная

Как же близка каждому айтишнику фраза: «Давайте сейчас закостылим, чтобы быстро сделать решение, а потом всё отрефакторим и сделаем нормально!» Именно такой подход приводит к появлению того, что называется техническим долгом. Есть рядом лежащее понятие легаси-кода, это когда вы ещё и все эти костыли принимаете по наследству и должны реализовывать доработки унаследованной кодовой базы.

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

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

Костыли

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

Разработчики говорят «закостылить». Определение костыля такое:

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

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

Так не делайте костылей, делайте всё правильно сразу, скажете вы. Но этот путь — верный способ навсегда испортить отношения с бизнес-подразделением. Почему, например, любой пользователь знает об Excel, а о Lotus 123 не знает почти никто? Потому что когда-то давно, после выхода процессора с новой архитектурой, разработчики Экселя закостылили решение, вышли на рынок раньше Лотуса, старая версия которого не работала на новом проце и захватили рынок.

Велосипеды

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

Под велосипедом («созданием велосипеда») в программировании подразумевают разработку того, что уже давно изобретено, причем часто в более продуманном и совершенном виде. 

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

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

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

Ричард Бакминстер Фуллер.

Ричард Бакминстер Фуллер

американский архитектор, дизайнер, инженер.

Архитектура

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

В семидесятые годы двадцатого века один строительный архитектор (Кристофер Александр) придумал и скомпоновал набор паттернов проектирования для строительной отрасли.

Язык шаблонов, Кристофер Александер.
Книжка Кристофера Александера «Язык шаблонов», настольная книга любого строительного архитектора.

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

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

Рефакторинг

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

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

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

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

Выводы

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

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

Услышь меня и вытащи из омута. Технический долг.

Что менеджеру проектов нужно знать о диаграмме Исикавы

Каору Исикава
Каору Исикава

Чаще всего, причины проблемы предельно ясны. У меня высокий инсулин, это плохо. Эндокринолог говорит, что главная его причина — лишний вес. Похудею — уйдёт высокий инсулин. Всё довольно очевидно.

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

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

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

ВНЕЗАПНО при помощи этой диаграммы можно также проанализировать причины успеха. Да, причины успехов надо анализировать, так же как причины провалов.

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

Но если ваша команда, как и моя сейчас, разбросана по пяти-шести часовым поясам, можно и онлайн. Неплохие средства есть в Miro, но с некоторых пор её нельзя купить, а в бесплатной версии ограничено количество досок, с которыми может работать команда. Я буду сейчас рисовать в Mindjet Mindmanager, благо там есть подходящий шаблончик.

Диаграмма Исикавы, корень
Диаграмма Исикавы, корень

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

Получается нечто подобное:

Диаграмма Исикавы для гипотетического проекта развёрнутая.
Диаграмма Исикавы развёрнутая

Хорошая диаграмма Исикавы обычно обширная, с большим количеством «костей». Если получилось простенько, возможно, у команды создания недостаточно компетенций, надо расширить состав участников.

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

  1. Уклонение;
  2. Митигация (смягчение);
  3. Делегирование (передача);
  4. Принятие.

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

А теперь советы и лайфхаки, которые помогут вам в составлении этой диаграммы:

01

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

02

Если работаете на бумаге или на белой доске, расположите «голову» в одной стороне доски или листа, а «кости» начинайте пририсовывать с противоположной стороны.

03

Начинайте с самых крупных и «жирных» причин и влияющих факторов, идите от более важных к менее существенным.

04

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

05

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

06

Помните, что ваш главный друг при составлении диаграммы Исикавы — слово «почему».

Давайте структурируем плюсы и минусы метода:

Плюсы:

  1. Метод легкоосваиваем и легкоприменяем. Низкий порог вхождения;
  2. Позволяет кратковременно включить креативное мышление у команды;
  3. Позволяет установить однозначную связь между разноуровневыми причинами и корневой проблемой;
  4. Дает возможность оценить влияние причин и факторов на проблему.

Минусы:

  1. Диаграмму невозможно проверить в обратном направлении (начиная от начальной причины к результатам);
  2. Не всегда имеет четкую структуру, что затрудняет ее анализ и возможность сделать объективные выводы;
  3. В диаграмме нет временного разреза;
  4. Плохо работает для слишком комплексных и системных проблем.

В целом, это всё, что пиэму нужно знать о диаграмме Исикавы.

Япония.