История о том, как NASA, ESA, Датский Технологический Университет, нейронные сети, деревья решений и прочие хорошие люди помогли найти мне лучший бесплатный гектар на Дальнем Востоке, а также в Африке, Южной Америке и других “так себе” местах.

Про саму UNIT-экономику формата USER —> PROFIT много всего написано. В этой статье расскажем про наш опыт ее применения в формате PRODUCT —> PROFIT. Будем искать ответ на вопрос: «Сколько нам нужно добавить товаров в наш интернет-магазин, что бы зарабатывать Х» + ссылка на калькулятор. Подход работает не только для интернет-магазинов, но и для производств, задумывающихся над расширением продуктовых линеек.

В преддверии старта практического онлайн-курса «Product manager» состоялся открытый урок с Сергеем Колосковым, продакт-менеджером Ozon. Участники научились находить метрики роста и строить аналитику вокруг них, а также считать и сводить unit-экономику. В этой статье мы приводим расшифровку занятия и полезные схемы и примеры из презентации.

---

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

Дано: собственные и аутсорс-проекты, некоторые участники работают удаленно.

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

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

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

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

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

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

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

Целью нашей разработки было создание с нуля учетной системы для одной из крупных российских компаний. Система была призвана заменить текущую, написанную в конце 90-х. В результате были реализованы платформа и один из бизнес-модулей. В реализованной части было порядка 120 объектов, 180 таблиц, около 30 печатных форм.

Хочу оговориться, что подход, описанный ниже, не универсален для написания любого ПО. Он подходит для систем уровня предприятия, которые строятся на основе объектно-ориентированного подхода: учетных, CRM-, ERP-систем, систем документооборота и т.п.

Вся документация на наш программный продукт состояла из следующих разделов:

• Общая часть
  • Список терминов и определений
  • Описание бизнес-ролей
  
• Требования
  • Бизнес-требования
  
  • Общие сценарии
  • Сценарии использования
  • Алгоритмы и проверки
  • Системные требования
  • Нефункциональные требования
  • Требования к интеграции
  • Требования к пользовательскому интерфейсу
• Реализация
• Тестирование
• Руководства
• Управление

Каждому из нас наверняка приходилось слышать один и тот же вопрос от своих родителей или друзей не из «программистской тусовки»: «А что вы там на своей работе вообще делаете?».

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

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

О том, что собой представляет так называемый Закон Мура на Geektimes, наверное, рассказывать в подробностях не стоит — все мы знаем о нем, хотя бы и приблизительно. Если вспомнить кратко, то этот закон — эмпирическое наблюдение, которое сделано Гордоном Муром. Формулировок самого закона было несколько, но современная гласит, что количество транзисторов, размещаемых на кристалле интегральной схемы, удваивается каждые 24 месяца. Чуть позже появилась разновидность закона, где фигурирует не два года, а 18 месяцев. Это связано уже не с Муром, а с Давидом Хаусом из Intel. По его мнению, производительность процессоров должна удваиваться каждые 18 месяцев из-за одновременного роста как количества транзисторов, так и быстродействия каждого из них.

Со времени формулировки закона разработчики электронных элементов стараются шагать в ногу с установленными временными рамками. Вообще говоря, для 1965 года закон был чем-то необычным, его даже можно назвать радикальным. Тогда «мини ЭВМ» все еще не были очень уж маленькими, занимая в помещении объем обычного рабочего стола, а то и больший. В то время сложно было представить, что компьютеры со временем могут даже стать частью холодильника, стиральной машины или другой бытовой техники. Большинство людей никогда не видели компьютер, а те, кто видели, почти никогда с ними не работали. Ну а те, кто работали, использовали перфокарты и другие не слишком удобные инструменты взаимодействия с ЭВМ, которые, в свою очередь, работали для решения достаточно узкого круга задач.

Введение

Недавно ко мне обратились, чтобы я посоветовал стандарты для написания технического задания (ТЗ) на разработку автоматизированных систем (АС) и программного обеспечения (ПО). Вот думаю, сейчас зайду в Яндекс, найду подходящую статейку и отправлю её. Но не тут-то было! Одной статьи, где перечисляются стандарты для ТЗ, включая шаблоны и примеры готовых документов, я не нашел. Придется сделать такую статейку самому…

И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification):

• ГОСТ 34
• ГОСТ 19
• IEEE STD 830-1998
• ISO/IEC/ IEEE 29148-2011
• RUP
• SWEBOK, BABOK и пр.

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

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

Пролог

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

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

Теперь я хочу рассказать, как можно качественно сформировать сами требования, ведя Заказчика от его «хотелок», к его счастливому и плодотворному сожительству с программным продуктом, его мечты.
Об авторских тренингах на тему: «Обучение проектированию ПО» подробнее можно узнать на моем YouTube канале

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

Привет, Хабр! Мы нашли очень крутую статью Designing Digital Products with Mental Models в блоге коллег из США, перевели ее и публикуем здесь. Автор статьи — дизайнер Тим Шеинер. Рекомендуем ее к прочтению всем, кто имеет отношение к разработке цифровых продуктов.

Лучший способ добиться взаимопонимания в проектной команде.

Перевод — это сложно

Когда-то, путешествуя по Индии, я купил недорогую книжку — «Преступление и наказание» Достоевского на английском. Я предвкушал, как с наслаждением прочту этот шедевр, но в итоге одолел его с большим трудом. Вместо восторга я испытывал недоумение: почему им так восхищаются? Как выяснилось позднее, текст, который я читал, был далек от первоисточника. Я узнал об этом, лишь добравшись до Бангкока, где попытался продать прочитанную книгу букинисту. Тот заявил, что ему она не нужна, поскольку перевод ужасен.

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

Теория систем рассматривает процесс как изменение системы. Действительно, любая деятельность — это действия, направленные на достижение результата, который выражается в том, что система обретает новое состояние. С процессами мы сталкиваемся в разработке, технике, химии и даже социологии. Однако каждый из нас ежедневно является участником рабочих процессов. Как показывает опыт, нередко руководители компаний избегают автоматизации и формализации процессов, им это кажется не совсем демократичным «закручиванием гаек». А напрасно. Грамотное построение и управление процессами в компании любого профиля помогает обеспечить адекватное взаимодействие сотрудников, обусловленное ответственностью и вниманием к срокам. Процессный подход не умер — он лежит в основе множества модных теорий управления разработкой, компанией, персоналом. Сегодня мы расскажем, где встречаются процессы, как ими управлять и нужны ли они вам в принципе.

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

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

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

Выбор подходящей архитектуры — ключевая часть построения фронтенда сервиса. Разработчик Анна Карпелевич рассказала студентам Школы разработки интерфейсов, что такое архитектура, какие функции она выполняет и какие проблемы решает. Из лекции можно узнать о наиболее популярных архитектурных подходах во фронтенде: Model-View-* и Flux.


— Добрый вечер. Меня зовут Аня Карпелевич. Мы сегодня с вами будем говорить про архитектуру фронтенда верхнего уровня.

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

Это старая версия статьи, новую вы можете найти перейдя по ссылке

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

Карл Маркс. Капитал. Том 1. Предисловие к первому изданию.

О бизнес-процессах говорят много и часто преимущественно в связи с автоматизацией бизнеса. Использую этот термин и я, в том числе, в своих статьях, посвященных CRM-системам, ERP, работе с BPMN-нотациями, IDEF0 и других инструментов, которые могут понадобиться в работе бизнес-консультанта и внедрении систем автоматизации. При этом в Рунете понятное и развернутое определение термина «бизнес-процесс» я не нашел.

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

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

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

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