Я пользовался методом управления проектами Scrum (скрам) с самого начала карьеры. Я изучал скрам в колледже. Тогда он считался лучшим методом управления разработкой программного обеспечения. Когда я начал работать, мне нравилось всё, что имеет отношение к скраму: ежедневные встречи, планирование, ретроспективные совещания, спринты и так далее. В конце концов, я пользовался на практике тем, чему меня учили.



Но через несколько лет я начал кое-что замечать: в последние дни спринта все бросаются доделывать всё то, чем занимались в предыдущие две недели, стремясь избежать переноса задач на будущее. Часто те, кто так поступали, брали на себя ненужный риск.

Почему? Разве какие-то задачи не могут подождать до следующей недели? Так ли важно доделать абсолютно всё до выходных? Нет, не так уж это и важно. А всё это происходит из-за того, что «Переносы задач — это плохо».

Предисловие переводчика

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

Статья Алексея Жеглова, аккредитованного канбан консультанта (AKC) и тренера (AKT) рассказывает о том, как отслеживать здоровье проекта с помощью накопительной диаграммы потока и как определять рабочие элементы, чтобы диаграмма отображала действительно полезную информацию.

Предисловие

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

Понимание вашего процесса как процесса коллективного накопления знаний

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

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


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

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

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

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

В двух словах, диаграмма накопления знаний / информации, представленная вот так,


мы можем представить вот такой Канбан доской:

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

---

^{Фото: Getty}

Почти за два десятка лет до того, как система MCAS компании Boeing погубила два новых самолета 737 MAX, Стэн Соршер знал, что все более токсичная обстановка в его компании приведет к какой-то катастрофе. «Культура безопасности», которая долго была предметом гордости, стремительно вытеснялась, по его словам, «культурой финансовой херни, культурой группового мышления».

Соршер, физик, проработавший в компании Boeing более двух десятилетий и возглавлявший там переговоры о создании профсоюза инженеров, стал одержим культурой управления. Он сказал, что ранее не представлял, что смелая новая управленческая каста Boeing создаст такую глупую и вопиюще очевидную проблему, как MCAS (Maneuvering Characteristics Augmentation System; система улучшения характеристик маневрирования, как ее окрестила горстка разработчиков ПО). В основном его беспокоило, что сокращение доли рынка будет уменьшать продажи и численность сотрудников, то есть то, что не дает спать по ночам постиндустриальным американским профсоюзным лидерам. В какой-то степени, однако, он все это предвидел; он даже показал, как убытки от запрета полетов самолета перекроют краткосрочные экономии от аутсорсинга в одном из своих докладов, который никто не читал, еще в 2002 году.

Совсем недавно на YouTube вышел новый видосик Максима Дорофеева «Где найти время?». В конце автор задавал вопрос зрителям о том, чего нам не хватает, чтобы выучить английский язык, стать хакером или саморазвиваться еще каким-нибудь способом. Несмотря на замечательную подачу материала, после просмотра осталось послевкусие легкой неудовлетворенности. Причину этой неудовлетворенности  я осознал через пару дней.

Источник

Mobius bike — это сервис по прокату велосипедов и самокатов, разработанный для Таллина (на данный момент запланировано расширение географии).

Гипотеза первого релиза — «приложение по прокату велосипедов, будет востребовано на рынке Европы». В декабре 2019 была пересмотрена основная гипотеза и теперь она звучала так — «может ли сервис по прокату велосипедов и самокатов получить максимальное распространение за счет удобства для конечного пользователя и франчайзи?» Для того, чтобы ответить на этот вопрос, нужно было реализовать следующее:

• провести работы по оптимизации структуры приложения (как внутренней — backend, так и внешней — дизайн и frontend) для внедрения нового типа транспорта и возможного масштабирования в будущем
• сделать условия аренды регулируемыми в админке

Любовь Никифорук — менеджер проекта

Ключевые экраны приложения Mobius bike до редизайна

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

Привет!

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

В статье "Contemporary Front-end Architectures" рассмотрены архитектуры фронт-энда с точки зрения потоков данных в исторической ретроспективе.

Материал состоит из трех частей

1. Теория и история
2. Реализация

3. Перспективы

Навигация по циклу постов: 1/5, 2/5, 3/5, 4/5, 5/5.

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



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

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

Вот некоторые темы, которые я хотел бы осветить в своих постах:

• Как устроен рынок IT-специалистов в Германии;
• Подготовка к поиску работы;
• Работа с вакансией: как подготовить резюме и cover letter;
• Как устроена цепочка интервью и что требуется на каждом из этапов.

Недавно я подсчитала, что за несколько лет работы в роли Скрам Мастера я провела более 100 ретроспектив в Agile-командах. О важности ретроспективы и том, как она отражает ситуацию в команде и влияет на ее развитие, хочу поговорить в этой статье.

Впереди много, очень много выходных… И если вы еще думаете чем заняться, то вот еще одна идея — посмотреть классный сериал. Сегодня публикуем мини-подборку 2020 года, которая погрузит вас в технологичный «О дивный новый мир» (ну почти). Все сериалы так или иначе связаны с IT и наукой — ну а как без этого!

Кто я?

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

О чем?

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

Многие уже слышали термин бирюзовые организации, который пришел из книги Ф. Лалу «Открывая организации будущего» (Frederic Laloux «Reinventing organizations»). Это стало модным трендом в последние годы, уже сформировалось целое сообщество сторонников этой теории, которая с разной степенью успешности реализуется в бизнесе.



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

Если ты стал руководителем в IT, то у тебя большие проблемы – достаточно сложно найти описанные модели организации производства и набора KPI's для CTO и CIO. Задача любого управленца любой отрасли – следить за конкурентами, «state of the art»- примерами и приносить лучшие практики в свою компанию. По своему опыту скажу, что тебе придется завести круг общения и делиться с другими СТО примерами в барах, на встречах, референс-визитах, конференциях.



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

Всем привет!

Я – Максим Скворцов, UX/UI-дизайнер Omega-R, международной компании по разработке и интеграции IT-решений. Я занимаюсь проектированием и визуализацией интерфейсов мобильных и веб-приложений.

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

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

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

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


Анатолий Дымарский (Сколтех) — физик-теоретик, работает в области физики квантовых систем. Анатолий расскажет, чем квантовый компьютер отличается от обычного и что сулят его возможности IT-индустрии.

Бывало ли с вами такое, что вовремя общения, чтения или изучения чего-то будто осеняет, какая-то из старых или нынешних ситуаций в буквальном смысле предстаёт в новом свете? Со мной это постоянно случается, в этот раз при чтении книги “Азбука системного мышления” Донеллы Медоуз.



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

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

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

Здесь и далее команда и система будут синонимами.

«Если не стыдно за первую версию продукта — вы вышли на рынок слишком поздно»



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

Многие слышали о пирамиде «data-information-knowledge-wisdom».
Интересно, что количество проектов про data несколько миллионов, про information — сотни тысяч, про knowledge — сотни, а по-хорошему, десятки, про wisdom — не встретил ни одного.

За год я просматриваю от 10 000 до 50 000 текстов на русском и английском. Тексты из категории «wisdom» иногда встречаются на Хабре и в блоге Пола Грэма, и чтобы систематически отлавливать (а позже и создавать) «черных лебедей» среди текстов, я придумал проект "Ontol.org". Сейчас мы опенсорсно пилим прототип MVP и параллельно я делаю некоторую работу вручную. Кому интересно — регистрируйтесь на Ontol.org, как только выкатим MVP, пригласим на закрытую бету.

В идеале «Онтол» — это подборка топ-10 самых крутых материалов на суперважную тему (многомерно проранжированная сообществом и экспертами), так, чтобы за 1 час человек мог ознакомиться с самыми полезными материалами человечества на эту тему. (+ top100 longlist менее важных материалов для дальнейшего изучения)

А пока — очень сырая подборка самых полезных материалов про удаленную работу на Хабре (UPD + vc.ru). (у кого есть ссылки на англоязычные материалы или с других ресурсов — пишите в комментариях.)

Практически каждый человек, который сталкивался с разработкой ПО знает что такое оценка задач в Story Points (SP), тем не менее периодически мне доводится рассказывать коллегам из других отделов или новичкам в команде, которые ни разу не сталкивались с таким подходом, зачем мы используем SP и почему это удобно для команды и эффективно для компании.

Цель этого текста – рассказать, что такое SP, как их использовать для оценки задач и почему эта методика получила такое широкое распространение.