Если вы хотите построить успешный бизнес в it-сфере, то для старта нет лучшего места в мире, чем Кремниевая долина. Мой опыт как СЕО компании Master Kit Corporated позволил сформулировать семь способов, позволяющих начинающему предпринимателю из России заявить о себе в Штатах.

Год назад компания Axelos представила четвёртую версию ITIL, библиотеки лучших практик управления ИТ-услугами. Один из ключевых её разделов посвящён руководящим принципам ITIL 4 (The ITIL guiding principles).



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

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

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

Как раз в «Основах», первой из семи книг новой библиотеки, подробно изложены руководящие принципы ITIL 4. Базируются они на известных методиках: Agile, Lean, DevOps и т. п. То есть guiding principles помогают интегрировать лучшие практики в единый подход к управлению ИТ-услугами.

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

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

Вероятно, каждый, кто работал над сложными проблемами, знаком с этим явлением: вы прилагаете все усилия, чтобы разобраться, терпите неудачу, начинаете заниматься чем-то другим – и вдруг видите решение. Это мысли, которые приходят в голову, когда вы не пытаетесь думать целенаправленно. Я всё более уверен, что для решения трудных задач такой способ мышления не просто полезен, но необходим. Проблема в том, что при этом вы можете только косвенно управлять своим мыслительным процессом. [1]

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

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

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

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


Ярополк Раш на конференции ProductSense

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

Может ли «красный» лидер быть эффективным? (Спойлер: Да, если он не красный).

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

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

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

Лидер идеального «красного» государства может смело сказать — «государство это я», а в идеальном «синем» государстве совсем нет лидера — жизнь там течет как известном романе Франца Кафки «Процесс». (с) KonkovVladimir

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

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

Я увидел этот вопрос на Quora и начал писать ответ. Но ответ получился слишком большим, так что я превратил его в эту статью.

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

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

Low-code платформы (Low code application platforms, LCAP) возникли как реакция на сложность и многообразие современных средств разработки ПО.

Согласно Gartner, одним из самых известных игроков в этой области является Mendix. Продажа Siemens за космические $700 млн. это подтверждает. Так что я буду использовать эту платформу как пример, хотя аналогичные выводы будут верны и для Outsystems, Appian, Kony, Betty Blocks и других.

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

То есть разработчики больше не нужны?!

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

Дальше я приведу несколько наборов слов, сгруппированных по типовым ошибкам. К каждому слову будет приложена транскрипция, приблизительная транскрипция на русском и ссылка на более детальную информацию в словаре. Так как большинство IT компаний все-таки работает с Северной Америкой, то транскрипции будут из US English.

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

Хотя люди обычно признают удобства ФП фич, ведь намного приятнее писать:

int Factorial(int n)
{
    Log.Info($"Computing factorial of {n}");
    return Enumerable.Range(1, n).Aggregate((x, y) => x * y);
}

чем ужасные императивные программы вроде

int Factorial(int n)
{
    int result = 1;
    for (int i = 2; i <= n; i++)
    {
        result *= i;
    }
    return result;
}

Так ведь? С одной стороны да. А с другой именно вторая программа в отличие от первой является функциональной.

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

Сегодня об ITSM и ITIL пишут все чаще — в том числе крупные площадки вроде Forbes и TechRadar. Охватить все многообразие источников и публикаций физически невозможно.

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

Дисклеймер

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

1. Структура доклада

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

Ключевая проблема для слушателя – отсутствие вводной части. Выводы он может сделать и сам, а вот стартовать с опозданием сложно и неприятно. Он ещё не понял, что вы будете про пищеварение, а уже нужно вникать в строение эпителия тонкого кишечника. Результат – ваш доклад попадает в слушателя не на все 100%, а имеет шансы и вовсе пролететь мимо.

Хотя Daily Scrum или Stand-up встречи принципиально отличаются от отчетных встреч, иногда первые становятся похожими на вторые. Чтобы этого избежать, давайте рассмотрим отличия хорошего эффективного Daily/Stand-up и не лучшей сферической встречи по статусу в вакууме, а затем будем стараться придерживаться хороших практик или избегать плохих.

В книге ”Masters of Doom” о компании id Software и её влиянии на массовую культуру Дэвид Кушнер размышлял о необычном стиле работы ведущего программиста Джона Кармака.

Чтобы повысить производительность и не отвлекаться от работы над движком Quake, тот принял агрессивный подход — начал постепенно смещать начало рабочего дня. В конце концов Джон садился программировать вечером, а заканчивал перед рассветом. Эти непрерывные отрезки тишины, изоляции и глубокой работы позволили ему создать первый в мире сверхбыстрый 3D-движок. Игра Quake произвела настоящий фурор.

Что самое важное для бекапов? Правильно, воспроизводимость. Поэтому давайте сделаем велосипед на коленке и на опции --link-dest у rsync. У нашего велосипеда не будет сложной структуры данных в стиле git как у restic, ни кучи бекендов как у duplicity. Но мы сможем восстановить его работу по памяти даже под стрессом.

Опция --link-dest позволяет указывать предудущую версию бекапа, на которую rsync будет ставить жёсткие ссылки, если файлы с прошлого раза не поменялись.

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

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

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

В советском журнале «Техника — молодежи» очень любили науку и фантастику. Поэтому частенько совмещали, публикуя в журнале научную фантастику.



Много-много лет, с 1949 по 1984 год журналом руководил легендарный редактор Василий Дмитриевич Захарченко, который, собственно, и сделал из него ту «Технику — молодежи», которая гремела на всю страну, стал легендой советской журналистики и был много куда вхож. Благодаря последнему обстоятельству периодически «Технике — молодежи» удавалось то, что мало кому удавалось — публиковать современных англо-американских фантастов.

Нет, современных англо-американских фантастов в СССР и переводили, и издавали. Но в периодике — довольно редко.

Почему?

TL;DR. Некоторые люди смотрят на мир иначе. Софтверная компания из Нью-Йорка решила использовать это как конкурентное преимущество. Её штат на 75% состоит из тестировщиков с расстройствами аутистического спектра. Удивительно, но необходимые аутистам вещи оказались полезными для всех: гибкий график, удалённая работа, общение в Slack (вместо личных встреч), чёткая повестка каждого совещания, отказ от открытых офисов, отмена собеседований, карьерная альтернатива повышению до менеджера и т. д.

Раджеш Анандан основал компанию Ultranauts (бывшая Ultra Testing) с соседом по комнате общежития в Массачусетском технологическом институте Артом Шектманом с одной целью: доказать, что нейрологическое разнообразие (neurodiversity) и аутизм сотрудников — это конкурентное преимущество в бизнесе.

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

Вопросы код-ревью меня интересуют очень давно. Много раз возникали те или иные проблемы то с качеством кода, то с климатом в коллективе. И действительно, code review — это если не единственное, то одно из самых главных мест для возникновения конфликтов в коллективе разработчиков.

И вот недавно при подготовке к очередному выпуску подкаста "Цинковый прод" я узнаю, что Google опубликовал свод правил по проведению Code Review, битком набитый ценными мыслями. Весь материал довольно объемный и не влезет в одну статью, поэтому я постараюсь выделить наиболее интересные (мне) мысли.

Итак, поехали

Теперь асинхронную связь внедряют не только на удалёнке

Иллюстрация: Yin Weihung

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

Только не совсем понятно, почему.

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

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

Всем доброго дня.

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



Более подробно в курс дела вводит первая статья: Невангеры
Продолжение, часть третья: Невангеры: Spice must flow
Часть четвёртая: Невангеры: Feed for speed