Рубрика «Управление продуктом» - 50

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

Какие ключевые проблемы в описанной модели:

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

Что мы предложили:

  1. В начальной модели нигде не фигурировали исходные данные на которых она была построена. Мы предложили внести эти данные в формате 2-ой нормальной формы в сам файл Excel на 2 отдельных листа (продажи и кол-во клиентов). Благо, данные по продажам в нашей агрегации по месяцам — это всего лишь десятки тысяч строк, а не миллионы. Так же мы настроили получение этих данных при помощи Power Query напрямую из базы данных.Читать полностью »

Многие российские машиностроительные предприятия внедряют и осваивают PLM (Product Life Cycle Management) – системы управления данными жизненного цикла изделий. Но под проектированием «в цифре» каждый подразумевает что-то своё. Так, я знаю организации, где отсканированные бумажные чертежи складируют в электронный архив и называют это переходом на цифровые технологии.

В этой статье я расскажу о том, как в принципе должно быть выстроено 3D-проектирование, а примером мне послужит Московский вертолетный завод им. М.Л. Миля.

Как промышленная революция 4.0 меняет технологию разработки сложной техники. Внедрение PLM на МВЗ им. М.Л. Миля - 1

Читать полностью »

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

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

Disclaimer:
Читать полностью »

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

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

Все, кто занимается такого рода прогнозированием, понимают, что в этом вопросе важна не столько точность прогнозов, сколько правильные взаимосвязи между вашими предпосылками и результатами. Ведь что мы хотим от прогноза? Мы хотим узнать, что будет, если делать все как обычно (AS IS) и что будет, если мы что-то поменяем (сценарии). Для того, чтобы сделать эту работу финансовая служба должна придумать какую-то модель предприятия, которой она может легко управлять, легко объяснять бизнесу как она работает и легко предоставлять данные в различных разрезах, в которых бизнес захочет это дело посмотреть.

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

Читать полностью »

8 октября в московском DI Telegraph пройдет Scrum Day 2018 — одна из конференций, которые по всему миру организует Scrum.org. Особенность Scrum Day в том, что точная программа конференции заранее неизвестна и упор делается на общение в малых группах. Каждый участник может заявить свою тему и затем обсудить ее с коллегами. Таким образом в течение дня параллельно раскрываются десятки актуальных тем. Подробная информация — под катом.
 
Scrum Day — конфа высокой концентрации смыслов - 1
Читать полностью »

— За что тебя приняли, за то и уволят. – тяжело вздохнув, сказал Боб. – Слышал такую фразу?

— Нет. – угрюмо ответил Джон.

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

— У меня своя версия. – тихо сказал Джон. – Кажется, дело было в скраме.

— Да, дело было в скраме. – кивнул Боб, все еще глядя в окно. – И я, если честно, уже не могу про него слышать. Не хочу говорить высокопарных слов, но ты меня обманул.

— Я? – недоуменно спросил Джон.

— Ты и скрам. Твой скрам. Твоя инициатива. – Боб повернулся и в упор уставился на Джона. Которая будет стоит мне проекта. И кучи денег.Читать полностью »

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

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

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

В конце 2017 года в Лаборатории было около 30 команд (может больше), и почти для каждой нужен был свой дизайнер. Даже на таком относительно большом масштабе важнее работать на уровне стратегии, верхнеуровневых понятий и подходов, потому то «контролировать» работу 30 дизайнеров, которые работают над разными продуктами и в разных командах и с разной скоростью технически качественно не получится. Тактику определяет каждая команда самостоятельно, в этом вся прелесть.

Читать полностью »

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

— Что за макулатура? – спросил Сергей, заглядывая через плечо Рустама.

— Сам ты макулатура. – обиделся Рустам. – Накладная это, на сборку.

— А нам ты ее зачем принес? – спросил Сергей.

— Да вон… — махнул рукой Рустам. – Даша опять чего-то намудрила, надо разбираться.

— Чего я намудрила, чё ты гонишь? – Даша была родом из деревни, что было видно невооруженным взглядом. Да она и не скрывала. – Мне сказали, я сделала!Читать полностью »

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

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

В принципе, софт можно написать либо вовремя, либо хорошо, но не то и другое одновременно*

* за исключением считанных случаев в сложившихся высокопроизводительных командах

Вот уже несколько месяцев я размышлял о том, почему создание качественного софта плохо сочетается с оценочными сроками и планированием вообще. За свою карьеру я видел проекты, выстроенные по самым разным моделям (каскадная, подлинно гибкая, гибко-каскадная), и у всех них была одна общая черта: независимо от того, над каким проектом мы работаем, если он делался «по науке» (т.e., мы не позволяли себе грязных уловок, из-за которых нам бы потом снились кошмары), то мы всегда срывали сроки.

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

Переведено в Alconost
Читать полностью »

16.01

— Коллеги, у нас серьезные проблемы с управляемостью. – с серьезным видом сказала Светлана Владимировна. – Если так пойдет дальше, компанию можно закрывать.

— Что вы имеете в виду, Светлана Владимировна? – спросила Марина, директор по качеству.

— А вы не знаете, Марина? – удивилась директор.

— Ну, я догадываюсь, конечно. – не захотела выглядеть глупо Марина.

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

— Тогда нам нужна система! – восторженно сказала Марина.

Остальные понуро молчали.Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js