Об опциях к приложениям

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

Потом разработкой стали руководить маркетологи и стали рождаться приложения с двумя-тремя настройками. Принцип — не заставляйте пользователя думать.

Сейчас ситуация средняя. В Макоси, например, сделали иерархию, оставив на самом верху системных настроек минимум разделов. В приложениях Майкрософт Офиса тоже отказались от полотен настроек, сделав всё компактно. В приложениях, которыми я пользуюсь активно — Mail, Ulysses, Agenda, Evernote, Todoist, тоже среднее количество настроек. Думаю, такая детализация опций сохранится и в ближайшем будущем.

О скрытых убийцах

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

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

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

Напишу точные названия нужных анализов:

• Гликированный гемоглобин HbA1С (HbA1С, Glycated Hemoglobin, GHB)
• Глюкоза (Glucose)
• Инсулин (Insulin)
• Холестерин общий (Холестерин) (Cholesterol Total)
• Холестерин ЛПНП (Холестерин липопротеинов низкой плотности, ЛПНП, β-холестерин) (Low-Density Lipoprotein Cholesterol, LDL Cholesterol)*
• Холестерин ЛПВП (Холестерин липопротеинов высокой плотности, ЛПВП, α-холестерин) (High-Density Lipoprotein Cholesterol, HDL Cholesterol)

Об общественном устройстве будущего

Я тут недавно публиковал нейросетевое видео об эволюции человека, которое предсказывает постепенное превращение людей в разумные гофрированные трубки. Но до этого ещё далеко.

 

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

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

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

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

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

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

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

Но до гофрированных трубок пока далеко.

О том, как важно иногда сдаваться

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

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

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

Очень важно вовремя остановиться.

Об аббревиатурах

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

Бизнес-подход к названиям мне нравится больше. Например, однажды я работал на украинскую компанию, занимающуюся всякой криптохернёй и у неё продукты назывались максимально мнемонично. Штука, анонимизирующая транзакции — «Чёрный плащ». Штука, раздающая криптокошельки — «Крипторевольвер».

Или Систех. Приложение для мобильной торговли называется «Мобильная торговля». Приложение для отслеживания торгпредов — «Локатор». Приложение для репликации данных — «Репликация». Приложение для OLAP-кубов — «Аналитика OLAP»

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

О хобби и KPI

Эксперты менеджмента учат, что ко всем рабочим аспектам надо прикручивать системность, KPI, расписания и другие вещи. Любой консалтер вам скажет: процессы не измеряются — значит, процессов нет. Так вот, худшее, что вы можете сделать — применить этот подход к хобби.

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

Я когда-то у своего блога считал статистику, следил, чтобы в каждом следующем месяце было больше посетителей, чем в предыдущем, пытался писать через регулярные промежутки (везде говорят, что чтобы блог стал успешным, писать надо регулярно и чем реже вы пишете, тем значительнее должны быть посты). Совершенно потерял удовольствие от процесса. Теперь пишу, когда захочу, посты совершенно произвольного объёма и получаю удовольствие.

Не вешайте на хобби KPI и будет вам счастье.

О важности своевременного отключения рефлексии

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

Тёрк идёт к главному хирургу Вэнгу и спрашивает, как так получилось. А тот отвечает — ты зачастую слишком много думаешь.

Ну да. Тёрк такой: «А какой доступ лучше сделать, а что будет, если не удержим давление, а что будет, если он начнёт кровить…» А Тодд в то же время: «Тум-тум-тум, красивый скальпель, тум-тум-тум, пора порезать». И добивается успеха.

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

О документах с полосочками

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

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

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

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

О подписках на селебрити

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

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

О чипировании в гуглодоках

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

Вводите @ а после него название чипа и гуглотаблицы подскажут подходящие варианты. Добавление чипа человека не открывает ему доступ к документу.

Ещё через меню «Вставка» такое можно сделать.

Об упущенных возможностях и разновидностях пальто

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

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

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

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

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

Армянин страшно смутился:
— Ну, знаете, там люди поумнее меня будут. А вообще, сейчас носят приталенные, чуть выше колена. Я не шучу, снимите шапочку и примерьте этот экземпляр. Так, он немного пустоват, но я не шучу — полчаса и мы переставим пуговицы на сантиметр правее и оно будет как раз. Пожалуйста, не думайте, что я давлю, одно слово и мы будем смотреть другие варианты. Кстати, не подумайте, что я пытаюсь вам что-то впарить, но специальные щётки далеко шагнули вперёд, есть несколько штук. Да, и этот шарфик вместе с приталенным пальто называется «Стиль Владимир Путин»…

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

Пальто, кстати, я у него купил.

Об обуздании зума

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

Опции → Звук → Автоматически включать звук компьютера при входе в конференцию.

Мгновения бесполезных действий сплетаются в года, их надо экономить.

Снова о приоритизации

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

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

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

О цифровых активах

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

Или какая-нибудь критичная для бизнеса интеграция перестаёт работать, потому что её не оплатили по причине из первого абзаца.

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

Если же вы маленькие и для вас такое ту матч, пусть всё важное регается на гендира.

О первом диске

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

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

Об обновлении на Вентуру

Для маководов. Три дня как обновился на Вентуру (13.0) Где-то полчаса качался дистрибутив, ещё полчаса система обновлялась. После обновления показала небольшую презенташку.

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

Со второго раза система переустановилась, флешка увиделась.

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

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

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

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

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

UPD: Я неправ, ящики отваливаются, звук глючит. Всё стабильно.

О важности протестов

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

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

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

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

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

Пришлось этот конструктор с позором выпилить и о подсказках забыть. Я не берусь подсчитать, сколько денег мы в эту функциональность закопали. И всё оттого, что ни у кого не хватило духу сказать гендиру: «Нет, мы не будем делать эту херню».

О самой дорогостоящей ошибке

В посте «Самая дорогостоящая ошибка, допущенная на работе», реддитор ZestyPing написал:

Я встретил Carl Page и Larry Page в 1998 году на вечеринке, которую организовал мой друг в Стэнфорде. 

Carl вручил мне визитку от eGroups и сказал «мы принимаем на работу». Потом Larry вручил свою от Google — дешевый кусочек картона, текст на котором очевидно был распечатан на струйном принтере — со словами «мы принимаем на работу».

Я сказал, «Не-а. Разве кому-то нужен еще один поисковик?» и ушел получать высшее образование.

Визитка все еще у меня.

О важности работы и участия заказчика

Работа заказчика для реализации проекта не менее важна, чем работа исполнителя.

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

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

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

1. Референсы внешнего вида.
2. Контент.
3. Чтобы он оплатил хостинг и домен, админпанель хостинга надо регать на него.

Хорошо, говорит он. На этом вопрос сайта встаёт на паузу. И далее, где-то два раза в месяц у нас повторялся разговор:
— Как у нас дела с сайтом?
— Ну, мне нужны референсы, контент и домен с хостингом.
— А, хорошо.

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

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

О теории и практике

Я хотел бы набросить на вечный вентилятор спора, что важнее, теория или практика. Как правило, в описаниях курсов сейчас пишут: «Только практические рекомендации, никакой воды» и считается, что это хорошо. Только практика, только реальные кейсы, только хардкор. 

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

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

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

О карьерных манипуляциях

А ещё вот как бывает. Вам накидывают обязанностей или повышают по грейду и повышают зарплату. Это называется карьерный рост.

А иногда просто накидывают обязанностей, но зарплату не повышают. Это называется карьерный нарост.

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

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

Плюс минус

Вычитал в Википедии про показатель «плюс-минус» в профессиональном хоккее. Его придумали в пятидесятые годы прошлого века, но считать для всех игроков НХЛ начали в 1967 году.

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

В скраме не принято смотреть личные метрики, только командные, но мне кажется, что аналог метода «плюс-минус» позволил бы намного объективнее взглянуть на вклад каждого члена команды.

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

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

Об источнике задачи в джире

Совет по Jira. Кому-то он покажется очень очевидным, но другим сильно поможет. Особенно актуально для больших компаний.

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

О мотивации

— А давайте введём систему мотивации!
— Отличная идея! Давайте введём систему KPI, при полном выполнении которой сотрудники будут получать 100 % переменной части, которую сейчас и так получают. А у кого будет меньше, будем снимать часть переменной части.
— Стой, у меня идея получше.

О важности грамотного завершения испытательного срока

Несколько слов о важности грамотного завершения испытательного срока.

Прочитал историю программиста Иннокентия, который устроился в одну модную и современную айти-компанию, но не поладил с менеджером. Токсичным оказался программист, если вкратце. Менеджер вёл с ним долгие беседы, пытался исправить ситуацию, но взрослых людей трудно перевоспитывать. Решил увольнять. Пиши, говорит, заявление. В 99 % случаев на этом всё успешно заканчивается, но не в нашем случае. Фигушки, ответил Иннокентий, платите мне два оклада, тогда уйду. А платить не хотелось.

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

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

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

В общем, завершение испытательного срока — это важно.

О незапланированных фичах

В появлении таких «незапланированных фич» прелесть геймдева.

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

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

1. Хливкие шорьки
2. Хрюкотающие зелюки
3. Мюмзики в мове
4. Бармаглота сын
5. Злопастный Брандашмыг

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

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

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

После того, как первый пункт будет реализован, презентуете его заказчику.

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

И только после этого вы садитесь расписывать требования ко второму пункту или пункту, ставшему вторым. Этот подход здорово экономит время на анализ и проектирование, минимизируя объём требований, выкинутых в мусорку.

 

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

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

Топы на вершине иерархии должны принимать решения совсем редко и эти решения должны быть наиболее важными для бизнеса.

 

Если загуглить слово «микрокоманда», поисковик возвращает множество статей про устройство микропроцессоров. Я хотел бы рассказать о немного другой микрокоманде — практике группового подхода к разработке. 

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

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

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

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

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

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

---

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

 

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

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

Оценка задач

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

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

Статус

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

Планирование спринта

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

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

Ретроспектива

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

Демо

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

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

Дейлики

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

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

 

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

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

Однако есть ещё одна проблема. Команда просит два месяца и через два месяца выясняется, что не успели. Вылезли непредвиденные технические сложности, заказчик накидал забытых требований, возникли проблемы с интеграцией с внешними апихами, много всего. И начинаются «вторые 80 %» проекта. 

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

 

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

Что такое DNS?

Domain Name System — это технология, которая позволяет браузеру вроде Firefox, Chrome или Edge найти запрошенный пользователем сайт по его имени. Если быть точным клинически, эта служба позволяет сопоставлять IP-адрес сервера с доменным именем. 

Каждому имени сайта соответствует набор цифр формата 000.000.000.000. Этот набор называется IP-адресом, примером реального IP-адреса является 192.168.0.154 или 203.113.89.134. Когда пользователь вводит в адресной строке браузера имя сайта, например google.com, компьютер запрашивает IP-адрес этого сайта на специальном DNS-сервере и после получения корректного ответа открывает сам сайт.

Вопрос со звёздочкой. Как происходит сопоставление IP-адреса и сайта, если на одном сервере несколько сайтов?

DNS-серверы отвечают за то, чтобы несколько доменов вели на IP-адрес, а веб-сервер с помощью механизма виртуальных хостов распределяет к какому из сайтов.

Теперь детали, как это работает. В частности, протокол HTTP 1.1 включает в себя заголовок, называемый «host:», который указывает, к какому веб-сайту на конкретном сервере клиент пытается получить доступ.

Таким образом, если snoopy.net и woodstock.org совместно используют 192.0.32.10 и ваш браузер пытается получить контент из http://snoopy.net/doghouse конкретного http-запроса, он будет выглядеть так:

GET /doghouse HTTP/1.1
Host: snoopy.net

Если желаемым URL является http://woodstock.org/seeds запрос будет выглядеть

GET /seeds HTTP/1.1
Host: woodstock.org

В обоих случаях между вашим компьютером и портом 80 сервера будет TCP-сокет. Сервер будет знать, как получить содержимое из /var/www/snoopy.net или /var/www/woodstock.org/ на основе заголовка Host.

Были бы другие заголовки для файлов cookie и другие вещи, такие как тип браузера и разрешенный контент, но именно заголовок «Host» — это то, что позволяет веб-серверу знать, какой виртуальный веб-сайт желателен.

Что такое кэш?

Кэш — это память с большей скоростью доступа, предназначенная для ускорения обращения к данным, содержащимся постоянно в памяти с меньшей скоростью доступа («основная память»). Кэширование применяется ЦПУ, жёсткими дисками, браузерами, веб-серверами, службами DNS и WINS.

Вопрос со звёздочкой. Какие уровни кеша существуют в вебе? 

Есть пять уровней кэша:

Клиентские

Ускорение получения веб-контента от веб-сайтов (браузеры или устройства)

DNS

Определение IP-адреса для домена

Интернет

Ускорение получения веб-контента от серверов веб-приложений Управление веб-сеансами (на стороне сервера)

Приложение

Повышение производительности приложений и ускорение доступа к данным

База данных

Сокращение задержек, связанных с запросами к базе данных

Что такое https?

HTTPS (аббр. от англ. HyperText Transfer Protocol Secure) — расширение протокола HTTP для поддержки шифрования в целях повышения безопасности. Данные в протоколе HTTPS передаются поверх криптографических протоколов TLS или устаревшего в 2015 году SSL. В отличие от HTTP с TCP-портом 80, для HTTPS по умолчанию используется TCP-порт 443.

Протокол был разработан компанией Netscape Communications для браузера Netscape Navigator в 1994 году.

(далее…)

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

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

По ощущениям, владение кодом стоит где-то в 2-3 раза дороже разработки. То есть, если вы потратили на фичу 100 часов, вам придётся потратить до 300 часов на её обслуживание за время жизненного цикла. Поэтому, как это ни парадоксально, лучший код — ненаписанный код. Меня этому научили ещё во времена одинэсничества. Лучшие специалисты решают проблемы клиента расстановкой галочек в одинэске и только если это решительно невозможно, берутся кодить.

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

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

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

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

Подавляющее большинство проектов проваливается. Понять, что данный проект провалится, не очень сложно. Есть несколько маячков.

Дедлайн спущен сверху

В практике постоянно натыкаюсь на ситуации, когда высокое начальство поговорило и решило, что срок 15 октября этого года. Или 2 ноября. Или 28 декабря. Как оно это посчитало — непонятно, потому что никаких планов нет даже близко, ещё даже не вполне понятен набор фич продукта.

Иногда дата, действительно, оправдана. Например, с 15 октября меняется форма отчёта, а продукт как раз и делается, чтобы генерить отчёты по новой форме. После 15 октября делать отчёты по старой форме бессмысленно.

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

Я делал такие проекты. Приходилось подключать дополнительные ресурсы, максимально упрощать фичи, экономить на качестве. Как правило, это приводило к тому, что проект был либо сдан вовремя, либо с небольшим опозданием, однако пользоваться продуктом было невозможно из-за багов и наступали «вторые 90 % проекта», когда попеременно наши тестировщики и приёмщики заказчика шлют баги, а разработчики их мужественно правят.

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

Планируют и реализуют разные люди или даже подразделения

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

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

Иными словами, оценивать должен тот, кто будет кодить/дизайнить/описывать требования. Иначе проект начнёт проваливаться очень быстро.

Руководитель проекта недостаточно квалифицирован или мотивирован

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

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

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

Не определились с особенностями реализации проекта

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

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

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

Не определены специфические критерии успешности проекта

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

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

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