Грамотная статья, классифицирующая стадии жизненного цикла компании. Начиная с идеи (основание стартапа) до поиска Product-Market-Fit (через MVP и поиск инвестора для экспериментов), далее идет выход на рынок и рост (growth/scale), после чего идет этап зрелости и оптимизации (Maturity).

Сразу же захотелось наложить эту классификацию на модель из Digital Practitioner. Уж очень стадии близки и ровно ложатся друг на друга: Team of teams – однозначно стадия роста, Enterprise – стадия зрелости и оптимизации.

А еще на модель из книги Crossing the Chasm. Product-Market-Fit – как раз этап преодоления пропасти.

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

Read more →

- posted in Стартап Архитектура

Человек меняет сферу деятельности. Это дается непросто, первые годы приходится очень много работать, поднимать большие пласты знаний и навыков, конкурировать со вчерашними студентами, у которых сил и энергии больше (а так же практически нет забот вне работы). Но, проходит время, человек разбирается в новой профессии, берет все более сложные задачи. И карьера внезапно взлетает в космос – вчерашние студенты остаются далеко позади, он проскакивает этап Сеньера, за пол года становится Тим Лидом и главой подразделения в 10+ человек, а через 2 года ему предлагают возглавить региональный офис на 150 человек, который он выводит из стагнации в стабильный и устойчивый рост (привет, Леша, не факт, что ты прочитаешь этот пост, но я все равно рад твоему успеху).

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

Как так происходит, что определяет успех нашей карьеры?

Hard skills – это еще не все

Очевидно, что суть в soft skills. Как только мы переходим из одной области человеческой деятельности в другую, нам приходится поднимать целый пласт знаний и навыков этой области (все это сейчас называется одним термином Hard Skills). Именно с приобретением таких навыков связана просадка в первое время, когда нам нужно конкурировать со вчерашними студентами.

Но как только hard skills подняты на нужный уровень – успех, карьера и, конечно же, зарплата взлетают вверх ракетой до пределов определяемых конкретной компанией. Компанией и тех soft skills, которые уже стали частью нашей личности за время нашей жизни.

Read more →

- posted in Карьера

Давно искал low-code решение для “домашней” автоматизации, что-то похожее на Integromat: автоматизация от которой не тошнит как от IFTTT, но не такое жадное до денег, из-за чего приходится считать количество шагов в процессе и количество обработанных данных, что нивелирует всю пользу от него.

Мне вообще нужно что-то похожее на AWS lambda+step functions для дома, а не для работы. Чтобы был low-code с минимумом обслуживания: как создания, так и конфигурации и поддержкой, и возможность сделать дашборд, чтобы смотреть что не так. Т.е. минимум гемороя (и программирования) и максимум пользы.

Пробовал AWS lambda (always-free хватает за глаза) – не зашло и не прижилось. Все равно сильно low-level для low-code ( :) ). Хоть аккаунт есть и могу делать лямбда функции, если упрусь в ограничения low-code платформ.

Но обо всем по порядку.

Low-code в [моей] жизни

У меня есть несколько телеграмм ботов на Integromate (Make) (из них, самый используемый – бот закидывающий книги в kindle), а так же домашняя бухгалтерия на IFTTT и Airtable. И количество интеграций растет по мере роста “хотелок”. Причем в полный рост столкнулся с последствиями философской максимы “бытие определяет сознание” – наличие удобных инструментов определяет что и как я не просто автоматизирую, а думаю, что это что-то можно переложить на “железного помощника”.

Вообще, тема low-code для автоматизации простых и рутинных операций очень жирная. Отправной точкой, как часто у меня бывает, стал vas3k (инноватор, по классификации crossing the chasm, во многих интересных мне областях; я же, соответственно, early adopter) со статьей: https://vas3k.ru/blog/nocode/. Статья хороша тем, что не только затрагивает тему, но и показывает несколько шикарных примеров автоматизации от домашних дел, до небольшого бизнеса. Рекомендую.

Что меня в “техно-зоопарке” сейчас:

Read more →

- posted in Home Automation Low-code

Знакомые поделились интересной презентацией Architecture for Flow with Wardley Mapping, DDD, and Team Topologies (так же есть книга с похожим названием).

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

А вот сегодня утром проснулся с ясной мыслью, что мы на проекте можем с помощью техник Wardley Mapping разложить наши DDD домены горизонтально в соответствии с их зрелостью (важно: зрелость не только внутри организации, а в индустрии) и вертикально по мере удаления от клиентов и value stream. Нам при общении с Продуктами (PM/POs) очень не хватает такого инструмента. То, что мы предлагали (Engineering Team) не встретило нужного энтузиазма. А вот Werdley Mapping достаточно прост, что его мы можем легко объяснить (вместе с benefits), так и в крайнем случае можем поддерживать его самостоятельно.

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

Сама презентация.

- posted in Architecture Product Management

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

В самом начале, когда мы выбирали какую систему взять за целевую (что же мы будем конструировать) проскакивала мысль, что очень важно выбрать то, что мы можем “заземлить”, перевести в физическую реальность. А если совсем просто, то выбрать то, что мы можем измерять.

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

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

Игра, как система

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

• Игровой процесс – процесс непосредственно связанный с игрой в Pirate Raid конкретного игрока на конкретном телефоне. Причем мы разделяем сам процесс (логически) состоящий из череды сессий “включения/выключения в игру”.

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

• Игровое поведение – решения игрока, которые он принимает во время игрового процесса.

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

Конструирование Игрового опыта через Игровой процесс

Представлю черновик V-модели конструирования игрового опыта.

Read more →

- posted in system engineering ssm

Продолжение серии постов про VP здорового человека.

Получается, что VP здорового человека - это предприниматель в большой компании, владелец бизнеса end-2-end. У этого бизнеса, внутри бизнеса, есть своя Value Chain. Свои отчеты о продажах (продукт ведь должны покупать) и затраты на производство, продвижение, … затраты на все то, что есть в нашей Value Chain. У него есть своя Value Chain. Свой P&L, бюджет. Он может стратегически развивать свое подразделение.

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

Продукты и разные VP

Раз все крутится вокруг продукта (то что покупают у компании), то VP – человек, отвечающий за продукт или линейку продуктов. Если двигаться выше, то SVP - за семейство продуктов (семейство линеек продуктов).

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

VP везде

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

На примере большой сервисной IT компании:

• Глава Java Global Delivery Organization (GDO) обучает и растит Java специалистов, команды Java-специалистов, Java-консультантов – это первый продукт.

• Их покупает проект конкретного аккаунта и перепродает клиенту предварительно собрав их, организовав в команду – это второй продукт (тут реальные деньги).

• Эту команду (или команды) клиент далее использует для создания своего продукта, …

Даже больше скажу, это уже пытались ввести на уровне всей компании. У Delivery Manager-ов проекта есть P&L, у Reporter-ов (глав больших юнитов, как Java GDO VS) он так же есть. Не слышал, чтобы он именно использовался для управления и развития. Но учитывается как один из KPI, health уровня.

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

Выбор за вами. Впрочем, как всегда.

Бонус.

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

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

- posted in Vice President career enterprise

Это будет серия постов про мое понимание тайтла* Vice President. Какие должности он может занимать, какие роли выполнять. Мне кажется, я достаточно неплохо приблизился к пониманию. Поехали.

Серия:

• VP здорового человека (этот пост)

• VP здорового человека. Копаем вглубь

• Организация, как набор бизнесов на общем фундамете

• Собираем VP- title назад: компетенции и навыки VP-здорового человека

• VP здорового человека. Противоречия, которые еще осталось разрешить

• …буду продолжать серию по мере появления мыслей

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

Сразу скажу, что рассуждать о VP (который title) как о роли или должности – неверно. Title – это как раз описание набора компетенций и навыков, которые умеет выполнять конкретный работник. И стоило бы начать с этого. Но знания и умения вряд ли дадут нам понимание зачем нужен VP и чем он отличается, скажем, от Директора. Поэтому я буду рассуждать о Должностях и Ролях, которые может занимать VP. Мне кажется, так будет понятнее, и уже из них можно понять какие навыки и знания ему нужны.

Так же важно отметить, что я считаю, что все VP-titles, выданные для мотивации, будут VP-нездорового человека. Так же как и все VP-тайтлы выданные, как часть пакета бенефитов тоже не является здоровыми. Да, они имеют право на жизнь, но по ним невозможно разобраться что это за title и какие компетенции ему нужны (кроме умения играть в гольф с SVP).

Еще одно важное замечание: Должность (в организации), Позиция (в проекте), Роль (так же в проекте) и title (как уровень квалификации сотрудника) – разные вещи. Пример: Андрей Ковалев, sr. solution architect по тайтлу, Head of Architecture, Java VS по должности, работает на проекте на позиции Delivery Manager (да, было и такое), но, в числе прочего, выполняет роль Business Analyst потому что эта практика на проекте хромает и ее нужно вытягивать. Конец отступления.

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

Какие работы может выполнять VP, которые не может (не готов) выполнять Директор, а так же что его отличает от C-level executives

Поехали. Начнем опять издалека (тема-то сложная), с иерархии отвественности:

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

• Менеджер – умеет организовывать людей в команды, чтобы они вместе могли выполнять общее дело. Решает вопросы с нехваткой работников, сроками исполнения. Недоступностью исполнителей, болезнями, отпусками, сменами… Отвечает за выполнение работ и достижение показателей. Но не отвечает за использование результата дальше (хоть и понимает, как этот результат укладывается в то, что делает компания).

• Директор – отвечает за конкретное капабилити (capability) в компании, отвечает за постановку и достижение показателей, умеет ставить цели по развитию этого капабилити в соответствии со стратегией. Не отвечает за выработку стратегии: что же мы развиваем и куда стремимся (хоть и участвует в ее выработке и почему она такая какая есть.).

• Вице-президент – мы тут, разбираемся что же это за фрукт.

• C-level executive – управляющий на уровне всей компании, отвечает за конкретные практики и типы работ на уровне всей компании.

В общем, получается, что VP отвечает за стратегию (чего-то), но не отвечает за всю компанию (там уже C-level). Так что же там может такого быть в компании, что требует своей стратегии, но не вся компания?

Вы уже понимаете к чему я веду: к Business Units – направлениям бизнеса в компании, отдельным продуктам и линейкам продуктов, которые продает компания. Т.е. эдакая мини-компания внутри большой компании. Вот за нее, по моему, и должен отвечать VP.

Выходит, VP – это предприниматель в большой компании, владелец бизнеса end-2-end. Но встроенного в большую компанию, поэтому ему не нужно решать многие, уже решенные, проблемы. А вот C-level executives нужно – они отвечают за всю организацию.

Получилось достаточно складно. Детали будут в следующем посте.

Примечания

1. Я прошу вас поспорить и покритиковать/попинать иерархию выше. Очень может оказаться, что я натягиваю сову на глобус и разница в уровнях не такая, тогда и понимание будет неверным. Давайте улучшать или даже исправлять его (понимание) вместе.

2. Википедия делает интересное замечание: “A vice president, also director in British English”. Т.е. в британском английском Vice President == Director.

Еще интересно, что если разбираться в тайтле Директор, то оказывается, что директора – это C-level executives (executive directors). Но “Large organizations may also have “assistant” or “deputy” directors. In this context, Director commonly refers to the lowest level of executive in an organization, but many large companies use the title of associate director more frequently.”

В общем весело у них там. А мы даже не говорим про плоские (flat) организации. В общем будем разбираться :)

1. Не знаю аналога title в русском. Ближе всего: погоны в армии. Вот “Слесарь II-разряда” – это что? Квалификация? Что находится в тарифной сетке? Вот не нашел. Зато нашел отличное описание требований к квалификации такого слесаря. Это специальность? Тоже нет. Вот и мучаюсь. Если кто поможет – буду рад отказаться от английского “title” или аналогии с армией и погонами.

- posted in Vice President career enterprise

Роль DevOps (менеджера) в организации

С одной стороны роль DevOps (менеджера) одна из самых важных в современной организации, в наше время экономики скорости (Economy of Speed, Death by Efficiency Is Slow and Painful). Ведь DevOps (как роль) отвечает за то, чтобы компания как можно быстрее и, главное, стабильнее вносила изменения в существующие продукты и доставляла их клиенту в готовом виде. Даже есть мнение, что именно их задача сделать так, чтобы всё работало на конце клиента.

В идеале поставка клиенту (от момента внесения последних изменений разработчиками) должна происходить по принципу “холодной и темной фабрики”, т.е. полностью автоматизированна (холодной и темной потому, что “роботам” не нужен свет и тепло, они могут работать и в темноте). Это задача DevOps.

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

Зона ответственности DevOps (менеджера)

Получается, что DevOps действительно находится в центре переплетения всего и вся в организации.

Read more →

- posted in system engineering ssm IT

Интересная дискуссия развернулась у меня с моим товарищем. Отправной точкой стала статья: https://aftershock.news/?q=node/1170960 и мысль из нее: “Идеология это инструкция по поведению для не способных понять идеи. Чем хуже в обществе фундаментальное образование, тем нужнее правителям идеология.”

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

1) Если собеседник напирает на то, что кто-то в чем-то неспособен или чем хуже образован – стоит насторожиться. Ибо это стандартный приём: противопоставляются мы и они (“мы” всегда умнее, не перепутайте!) и сознание перестает критически осмысливать продолжене. Плюс этот примем использовать можно всегда и везде и объяснить все что хочешь.

2) Давайте заменим слова в высказыании:

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

“Процессы это инструкция по поведению для не способных понять идеи. Чем хуже в команде фундаментальное образование, тем нужнее руководителям процессы.”

Близко к жизни? Давайте еще ближе:

Read more →

- posted in государство

Все же “вернул взад” команду разработки на уровень Создателя. А Ops команду перевел в сам продукт. Мы все-таки не пересобираем целевую систему для каждого клиента. Он ее получает в сборе и пользуется как есть (как сервис). Сейчас не собираем. Вот если бы у нас была SaaS-платформа… То да, мы бы собирали продукт для каждого пользователя индивидуально (и это тоже можно делать холодной фабрикой). А потом, после сборки, мы ее будем поддерживать как и все остальные продукты.

Вот наша Бизнес Команда действительно собирает продукт под клиента (там страховки для компаний с 1000+ человек, на миллионы денег, так что можно и собрать конкретную под нужды клиента), а потом передает в другую команду, которая будет этот продукт (Страховку/Policy) поддерживать (дальше по Value Stream).

В общем “протекла” аналогия с супермаркетом в моем случае. Но не протекла для Игры. Можно даже до-аналоги-зироваться до сотрудников на зарплате, которые помогают в онлайн игре получать “опыт” (какой именно опыт-то?) игрокам. Причем это не фантастика. Я где-то про это читал недавно – выгоднее нанять недорогих сотрудников для таких вещей, чем писать сложный алгоритм для NPC.

Про пользу от Стади Группы. Натолкнул меня на мысли выше разговор с Андреем (мы с ним готовили материал для занятия во вторник) когда он обратил мое внимание на то, что Целевая Система не только Продукт, но и Сервис (когда мы, как поставщик, берем на себя не только сборку и поставку продукта, но и часть Жизненного Цикла эксплуатации, как с прической в парикмахерской). Причем, вот засада, моя “слепота” происходила не от того, что я не разобрался в разнице между Продуктом и Сервисом. Нет, я разобрался в их различии. Проблема в другом – я изначально использовал слово “продукт” в смысле принятом у меня в индустрии – как продукт+сервис. И, соответственно, я поместил Ops Team (того самого парикмахера) в цепочку создания. А он в сервисе. Где парикмахерская – система создания, которая не только создает (новые прически), но и поддерживает (support) новые.

Чувствую, что начал запутываться (в парикмахерских). Поэтому прервусь на этом :)

Вот как бы я на это обратил внимание без Андрея и без Study Group? С ментором я обсуждаю “высокие материи” (VP-здорового человека и разработка Windows как платформы с множеством продуктов на этой платформе). С ребятами на работе мы заполняем таблицы по шаблону, который в 90% случаях создаю я и валидирую с ментором. Обсудить СМ как СМ мне было не с кем (кроме чата поддержки, но там не очень комфортно показывать, что я что-то не знаю – заклюют).

- posted in system engineering ssm IT

Получилось найти свое место в цепочке создания продукта клиента с точки зрения Системной Инженерии (3е поколение).

Какие продукты (сервисы) мы продаем клиентам

Мы выделили 3 категории продуктов, которые может предоставлять компания, которая занимается Professional Services в IT.

1) Продукты стратегического уровня: какие capabilities нужно создавать и развивать, чтобы достичь стратегических целей.

2) Продукты уровня развития: как создавать и растить такие capabilities (на стороне клиента). Тут все вокруг практик+методов.

3) Продукты уровня разработки (система создания): команды, которые встраиваются в команды клиента, которые (команды клиента) создают IT систему, которая встраивается в систему создания Business продукта клиента, результатом которого является бизнес-продукт (например Страховка).

На картинке ниже показано наше место в цепочках создания для продукта 3го уровня (Dev Team):

Read more →

- posted in system engineering ssm IT

Не зря я не читал обсуждение в чате Экзокортекса (а началось все с очень банального – Anki карточек). В бурных обсуждениях лучше не участвовать, а подождать и прочитать все вместе. Тогда и думать получается концентрирование. И мысли получаются обобщенные, а не конкретные, направленные на одну деталь.

Вот начало обсуждения. Очень много хороших мыслей. Я все полезное (мне) не вытянул. Но не важно. Вытяну в следующий раз. А что такое же обсуждение все же будет еще раз – уверен. Поехали.

Мышление письмом и AI/ML/GPT

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

Как не помогает чтение чужих meeting notes. Они, во всяком случае для меня, мало полезны (только в том приложении, чтобы понять что же было интересно другому человеку/другой роли). Так и ML не поможет – после обработки для вас это будет новая информация.

Вот использовать такой AI для составлении краткой справки по теме – это да. Но возникает вопрос доверия. Ассистента вы хотя бы сами выбираете. И можете учитывать его компетенции при постановке задачи. AI до этого уровня пока не дошел. Но будет там 100%. Тогда и поговорим :)

Вообще пользу от ML/GPT/(любой автоматизации) можно оценить с помощью мысленного эксперимента: заменить ML/GPT на быстрого и исполнительного ассистента-человека. Если от такого ассистента будет польза, то идея стоящая. Если нет - то нет. То же самое с голосовыми помощниками – если бы это был другой человек, было бы лучше/проще.

Read more →

- posted in exocortex ssm productivity

Долго не мог совместить Lean/Kanban и современную организацию работ с разбиением на Features и на Epics, которые используются в большинстве agile-процессов. Причем если с фичами все понятно: бьем типичную фичу на части, начиная с наименьшей части (MVP) и развиваем ее итерациями, где каждая итерация – это новая фича.

Т.е. как совмещать lean и features созрело давно, но было непонятно как встроить это в Product Management и планирование крупных кусков работ. Эпики долго не давались. И вот недавно, как мне кажется, у меня получилось.

Что такое Эпик.

Можно выделить 2 подхода к определению того, что такое Эпик:

• Эпик – законченный кусок функциональности, который приносит пользу end-2-end.
• Эпик – это какая-то инициатива, направление, которое нам помогает сфокусироваться на достижении этой цели.

Первый вариант – это то, что используется чаще всего в индустрии. У Эпика есть четкое описание, его scope, так и видишь результат, читая его. Да, его не просто добиться (это будет серия фич, которые разработчики будут бить на Story и работать над ними). Хочется сразу же применить к Epic подход выше, выделить MVP Epic и развивать его дальше, но этот подход порочен: эпики – максимальный уровень группировки работы, с которой работает команда. Их не должно быть много, иначе у нас будет огромный бэклог и мы будем тратить много времени на их поддержку.

Ок. Эпик – это законченный кусок функциональности, который не стоит бить на части, выделяя MVP и итерации. Тогда, получается, мы заранее знаем что мы хотим получить и можем расписать фичи на весь объем работ. Где тут гибкость? Где циклы обратной связи, где обучение и реакция на поведение пользователей? Старый добрый waterfall.

Read more →

- posted in product management lean agile

Звучит контринтутивно, но да, можно. Люди это успешно и давно делают.

Модель рассуждений

Если конкретнее – нужно обсуждать не общие слова “сознательное/бессознательное”, “когнитивно/некогнитивно”, а более четкую модель. Которая бы помогла нам договориться что же мы имеем ввиду под “сознательное/бессознательное” и ответить на вопросы.

Предлагаю следующую: в нашем мозге есть 2 части “Лимбическая система” и “Неокортекс”. Первая досталась нам от предков-животных, вторая тоже от животных, но развилась настолько, что мы можем обсуждать абстрактные понятия.

Либическая система – это то что мы не контролируем, это наше несознательное. Она дико эффективна, а главное использует “хаки” в виде гормонов и наркотиков. Которые забарывают “сознательную” часть на раз.

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

Read more →

- posted in thoughts phycology Савельев

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

В этот раз я зацепился за статью Энергопоток будущего (которого не будет). В котором задается вопрос: каким будет мир, если потребление энергии конретным человеком (как мы с вами) возрастет в 1000 раз?

2 цитаты:

“Ладно, речь не об этом. Надо понимать, что вот эта вся роскошь современной жизни на Западе, в России вызвана лишь дешевым и огромным энергопотоком. Ни в одном учебнике физики, химии, обществоведения не написано в качестве закона про то, что сраный водитель фуры может жить в собственном отдельном доме на 150 м2, там держать зимой 22 градуса, а летом 20 градусов. При этом есть еду, которую привозят из 50 стран мира прямо в магазин в его городке. Иметь роскошь кататься на собственном пятиместном автомобиле (мощность которого позволяла бы перевозить и 20 человек) в одно лицо куда угодно каждый день. Летать через пол-планеты на какой-то пляж…

Read more →

- posted in thoughts future

Несмотря на то, что прошло всего несколько дней с момента создания Гомельского Архитектурного Сообщества, нас уже 60 человек (а мы ведь даже еще и не начинали ничего делать)! Значит, тема интересна многим из нас, и мы не зря организуем сообщество.

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

Первая встреча пройдет 24 ноября в 7 часов вечера в кафе «ФЛЭТ» (как раз успеть доехать до гостиницы “Турист” после работы). Мы не хотим большой аудитории, это не конференция. Это, скорее, клуб по интересам. Будет человек 30.

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

Read more →

- posted in architecture SA Community

В последние годы значительно вырос спрос на специалистов в области проектирования и дизайна систем. Что и не удивительно, потому что приложения и системы с каждым годом становятся все сложнее. Размер команды и команд участвующих в одном проекте растет. Бизнес (заказчик) хочет недорогих решений и быстро. С этим всем приходится сталкиваться Архитектору Программных Решений (Solution Architect или сокращенно SA). Наша индустрия хоть и молода, но уже накопила множество готовых решений, начиная от библиотек и фреймворков до подходов, практик и паттернов.

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

Read more →

- posted in architecture SA Community

Помните картинку “как нарисовать сову”? Мол рисуем две окружности и добавляем все остальное. То же самое происходит с дизайном системы. Берутся требования и… превращаются в архитектуру системы. И совершенно непонятно почему тут ASP .Net MVC, тут Message Queue, а тут availability кластер. И есть ли обоснование для кластера и MQ в требованиях? Тоже непонятно.

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

А потому, что исходя из

Read more →

- posted in architecture approach

В понедельник начался курс по Энтерпрайз Архитектуре на open2study Introduction to Enterprise Architecture. Я вчера закончил первый модуль этого курса. Очень нравится. Не напряжно. У меня ушло где-то 1.5 часа в 2 приема.

Рекомендую.

Enterprise Architecture

Энтерпрайз архитектура это “a well-defined practice for

Read more →

- posted in TOGAF e-learning EA

Я провел 6 Unified Assessment сессий на Солюшен Архитектора (SA) в этом году и несколько в прошлом (что это такое смотрите в конце сообщения). И я вижу большую проблему с пониманием того, кто такой Архитектор, его роль и обязанности. Большинство кандидатов и их руководителей не понимают кто такой SA, что он должен делать, и чем он отличается от разработчика. Кроме того, у всех отсутствует системный подход к созданию архитектуры.

Эта проблема давно известна, и ее решением ЕПАМ активно занимается. Для этих целей, например, была создана

Read more →

- posted in EPAM approach whiteboarding architecture

Возможно вы знаете про конференцию MS //build/ прошедшую в конце апреля в Сан Франциско. Это самое большое событие Майкрософт в году на котором она анонсирует новые продукты, а так же задает направление развития на весь год.

Read more →

- posted in windows dotnet microsoft

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

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

Read more →

- posted in CC results

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

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

Read more →

- posted in CC consulting

Коллеги показали игру 2048. Смесь пятнашек с… эээ… тетрисом, что-ли. Сама игра меня не сильно заинтересовала (был очень занят по работе), но вечером меня торкнуло и я решил сделать бота для нее. Захотелось применить пылившиеся знания по основам AI полученным после прохождения курса CS188.1x: Artificial Intelligence на edX.

Результат можно посмотреть на

Read more →

- posted in AI

Если вы, как и я, изучали .net в “боевых условиях” под лозунги “вперед на мины, за вами Родная Компания”, а первым встретившимся вам инструментом логирования был log4net, вы, позже, узнали про стандартные средства логирования в .net (System.Diagnostics.Trace, например), но не видели смысла разбираться с еще одним логером, когда

Read more →

- posted in loggin practice

Вы знали, что google календарь может отправлять СМС напоминания? Скорее всего да. Я сам этим пользуюсь постоянно. А знали ли вы, что с помощью таких напоминаний можно сделать себе СМС оповещения? А вот можно. Эдакий персональный бесплатный СМС гейт. Я об этом когда-то давно читал, но тогда мне это нужно

Read more →

- posted in python django

Всем кому лень читать, вот цитата:

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

Смотрите, как просто получается: сначала моя задача — потом книга

Read more →

- posted in stratoplan

Наконец-то дошли руки поставить nginx на тестовый сервер, что позволило избавиться от всех этих kavaleu-al:1080, kavaleu-al:8500, kavaleu-al:3000. TeamCity-серверу повезло еще больше, он получил свой собственный субдомен teamcity.kavaleu-al вместо “стыдного” kavaleu-al:8080

Что я люблю в современном IT, так это то, что большинство вещей решаются за 10-20

Read more →

- posted in nginx

Отличный ролик в котором за 15 минут (реальных) на русском рассказывают о принципах гибкого управления продуктом. Это перевод на русский язык видео-презентации Хенрика Книберга Agile Product Ownership in a nutshell. Сделанный Борисом Вольфсоном. Ссылка на оригинальное сообщение на хабре.

Я составил содержание ролика для удобства и привлечения внимания.

Read more →

- posted in pm agile

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

Воркфлоу наш очень прост:

Read more →

- posted in paypal

Думаю, вы уже сталкивались сайтом http://xkcd.com/ и его комиксами, нарисованные Рэндаллом Монро, сотрудником NASA (если нет, то рекомендую, Уверен, что есть переводы этих комиксов). В 2012 году этот проект дополнился блогом http://what-if.xkcd.com/. В котором Рэндалл отвечает на глупые, на первый взгляд вопросы.

Перевод выкладывается на

Read more →

- posted in

Если вас интересовало зачем я развел всю эту бурную деятельность в блоге (1, 2, 3), проводил семинар и грузил людей в личном общении, а главное какая польза от этого всего лично мне, то это сообщение должно прояснить вам мои мотивы. И не только прояснить, но и, надеюсь, побудить вас откликнуться на мое предложение или даже, чем черт не шутит, помочь мне в осуществлении моих планов. А планы у меня не больше не меньше, а “захватить мир”… Заинтриговал? Надеюсь. Поехали.

Read more →

- posted in stratoplan consulting

http://bigocheatsheet.com/

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

Я сделал всего ДВА скриншота. По ссылке информации много больше.

Что эти все O(n*log(n)) означают на практике:

Характеристики структур данных:

Задачки на осознание

1) В каких ситуациях QuickSort (“Best ever”, фактически стандарт сейчас) может дать “плохой” результат, хуже любого другого алгоритма (дает (O(n^2)).

2) В каких случаях Insert Sort (или BubbleSort) рвет все другие алгоритмы сортировки (выдают O(n))? // hint: частично отсортированные данные

3) В каких случаях HashTable превращается в LinkedList (со всеми вытекающими) и что с этим делать? // hint: алгоритм хэширования

4) Ваш алгоритм на HashTable стал потреблять слишком много памяти, что можно сделать? // hint: найти другую структуру данных, можно по шпаргалке выше.

5) ….

… … …

Read more →

- posted in

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

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

Read more →

- posted in

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

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

Основная цель – устроиться на работу “хоть куда”/”хоть за еду”. Потому что я твердо уверен, что обучение в “боевых условиях” на порядок эффективнее.

Read more →

- posted in

4 часть сообщения “Инструменты управления. Стратоплан, 30.11. Обзор”, начало вы можете найти здесь. Продолжим.

Как я уже говорил, отличная секция. Грамотные, компетентные ответы. То что я записал/запомнил (могут быть неточности! Как, впрочем, и везде)

В: Какие книжки посоветуете?

О: Книжки это про знания, не про умения. Чтобы получить умения нужна практика, которая запускает Цикл Коба. Книжки можно найти http://www.stratoplan.ru/books/

Read more →

- posted in stratoplan

3 часть сообщения “Инструменты управления. Стратоплан, 30.11. Обзор”, начало вы можете найти здесь. Продолжим.

4 принципа конструктивизма

Своевременность: Проблему нужно решать своевременно (а не после). Адресность: Проблему нужно решать с людьми которые могут ее решить (а не с женой на кухне, другом в курилке). Факты и данные: Нужно подтвердить наличие проблемы

Read more →

- posted in stratoplan

2 часть сообщения “Инструменты управления. Стратоплан, 30.11. Обзор”, начало вы можете найти здесь. Продолжим.

Алгоритм решения проблем с людьми.

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

Read more →

- posted in stratoplan

В субботу (30.11.2013) прошла трансляция вэбинара “Управленческие инструменты: 16 концептов на каждый день” о которой я рассказывал на доске. Масса впечатлений, мыслей, новых задач, переосмыслений, впрочем я именно этого и ожидал после первого стратоплана этим летом. Александр Орлов рассказал о 16 инструментов, которые мы можем использовать каждый день на работе, а так же в жизни, для прояснения чего-то, мотивации и саморазвития.

Кто такие Стратоплан вы можете узнать на сайте. Я могу только сказать,

Read more →

- posted in stratoplan

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

Сам курс: http://www.coursera.org/course/reactive

Его обзор на Хабре: http://habrahabr.ru/post/200338/

Перевод Реактивного Манифеста: http://habrahabr.ru/post/195562/

Read more →

- posted in e-learning

Продолжаем, дайджест ссылок.

Все сейчас движется в стороны вэба, а в вэбе в абсолютных лидерах html+css+js. Похоже, лучше всего в эту сторону двигаться. Отличный сборник того что же нужно рассматривать в первую очередь: Changing Times For Web Developers – 6 Tips You Should Read To Survive

Read more →

- posted in

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

Начну с двух вещей которые очень впечатлили на этой неделе.

Read more →

- posted in

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

Глаза, как и любую часть организма можно

Read more →

- posted in

Это продолжение серии статей о принятии ответственности. Предыдущая статья была здесь.

Давайте ответим на несколько вопросов (каждый себе, а после я попробую).

• Хорошо ли работала команда для того, чтобы выпустить продукт в срок?

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

• Кто виноват в провале?

• Кого можно сделать виноватым?

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

• По мне очень хорошо. Не уверен, что реальная команда сделала хотя бы половину. Другое дело, что ни пытались тушить пожар, когда “дому было бы лучше сгореть”, ИМХО.

• Написать письмо вместо звонка. Отказаться помогать “сегодня выходной, что ты от меня хочешь”, “я на ДР и я пьяный”, “я к теще собираюсь”, “моя жена итак меня ненавидит”, …

• Я не могу назвать виноватого. По мне все виноваты в разной степени. Даже тестер, хотя я “играл” за него.

• Любого. Обычно это самый молодой и/или нестойкий. Р за то, что поздно предоставил. А за то, что сервак сломался и отключил наш сервис. Т за то, что все же пропустил баг.

Read more →

- posted in

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

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

Живописание ОПЫ закончено, начинается собственно разбор полетов:

Read more →

- posted in

Обнаружил видео с доклада Гапертона (Владислава Балина) на Software People “Проектирование как процесс решения проблем”. Об этом докладе я узнал почти год назад. Далее Влад выложил слайды.

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

Основные тезисы

• Разработка это не конвейерное производство, а проектирование от начала до конца (код – это не более чем тех документация для конвейера который производит ПО).
• Разработка это решение проблем. Проблема имеет не одно решение, а множество (пространство решений) 8m45s

Read more →

- posted in

Многие, думаю, в курсе про техники Тайм Менеджмента, в инете их вагон, пиарных статей куча. Самая известная, наверное, это GTD.

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

Read more →

- posted in