Андрей S_A

Предыстория

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

Далее подробнее.

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

Доброго времени суток. Хотелось бы порассуждать об одном из известных аспектов проектов — ресурсном. Предпосылка такова — если открыть, например, учебник Мазура, Шапиро, Ольдерогге «Управление проектами», то там сходу проект рассматривается как «процесс перехода из исходного состояния в конечное— результат при участии ряда ограничений и механизмов».

То есть сначала была идея (сайта, софта, оказанной услуги), затем её конкретная вещественная реализация.

Реализация, очевидно, является цепочкой преобразования одних ресурсов в другие, как и любое производство. Этот пост будет посвящен рассмотрению ИТ-проектов если не как производства, то как ряда преобразований уж точно.

Всем добрый день!

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

Преамбула
Неоднократно сталкивался с картиной: от менеджера требуют сказать конечный срок и дают в руки трекер задач. Решение бывает такое — план проекта в MS Project/TeamWork или в каком-то привычном для Waterfall инструменте, а для трекинга кастомизированная Jira/Trello или что-то еще. Глядел я на мучения менеджеров с актуализацией туда-сюда, и родилась идея поженить Waterfall и Kanban: методически и практически (в рамках наколенно-доморощенной реализации на Gtk#).

Всем добрый день. В комментариях к посту Waterfall и Agile: и всё-таки, откуда эффект? были высказаны пожелания помоделировать ход проектов. Сразу скажу, что на большее, чем на статьи в жанре «записки на салфетках» меня не хватает, увы, но тем не менее тема интересная и триальная Wolfram Mathematica доступна и умеет работать со стохастическими дифференциальными уравнениями. Например:
dprogress(t) = plan(t)*dt + risk(t)*dw_t
В данном короткопосте будут подставлены конкретные plan и risk. Сразу говорю, особых чудес не будет.

Всем добрый день! Этот короткий пост посвящен рассмотрению моделей процессов разработки Waterfall и Agile (на примере Scrum и/или Kanban). И вот в чем дело: с точки зрения заказчика, процесс не столь важен, сколько срок и бюджет удовлетворительного с точки зрения функционала результата. И если известно, что (изменения не учитываются) затраты Waterfall-процесса идут по S-кривой, а затраты Agile-процесса накапливаются линейно (так как ресурсы используются одновременно все), то как они должны различаться по эффективности. Чтобы исследовать этот вопрос, необходимо построить модели и сравнить их, и для этого будет использована несложная математика.

Всем добрый день! Так случилось, что комментарии в теме «Управление проектами: операционный vs. проектный подход» предварили мой недельный отпуск. Я решил провести его с пользой и высказаться в некотором формате по вопросу портфельного управления. Формат изначально предполагался быть книгой (а это по стандарту ЮНЕСКО минимум 49 страниц), но потом я решил что это достаточно много для тех, кто занят вопросами портфелей (и вообще я человек, страдающий краткостью). Поэтому — брошюра.

Доброго времени суток! Недавно узнав о таком инструменте моделирования, как язык Modelica и его свободной реализации OpenModelica, был удивлен тому, что на Хабре по этому поводу всего одна статья. Поскольку тема несколько необычна, детали пришлось постигать на собственной шкуре некотором взятом из головы примере. В этой статье пойдет речь о том, как построить простую модель сражения (для примера), попутно разобравшись с некоторыми концепциями языка (основное).

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

Поскольку TermKit так и не допилили пока еще, смотреть хотя бы картинки в терминале — наверное было бы неплохо всё же (тем более что тут и тут говорят так). Да и самому мне это полезно, при работе с веб-проектами. Попробовал написать proof-of-concept-прототип. Под катом скрины, небольшое описание работы и ссылки на код.

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

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

Долго я смотрел на пустой блог "Управление продуктами" с призывом что-нибудь написать, и решил что-нибудь написать. Но тема ближе к управлению проектами. Полагаю, управление продуктами больше про NPD и иже с этим, нас же будет интересовать доходность и риск портфеля проектов. Разве не максимизация дохода при заданном уровне риска цель портфельного управления? (Вопрос риторический).
Сразу говорю, речь о собаках, звездах, дойных коровах и так далее не пойдет.
Update: пример. Вопрос — от чего бы Вы отказались, имея полторы тысячи на следующие 3 года?

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

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

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

Этот пост больше про подсчет финансовой эффективности проектов (бизнес-планирование) на примерах из ИТ, поэтому если кому интересно — прошу под кат.