Я рекомендую раделять процесс разработки продукта от проекта. И не считать Agile способом управления проектами. Я могу порекомендовать что-то из инструментария Agile, например регрессионное тестирование, но само чистое применение Agile в проектах без «слоя сверху» — осуждаю (лично), но рекомендую взвешивать все за и против.
Вы сравнивали по стоимости ваш процесс с процессом с ТЗ?
Мне видится, что на работу без ТЗ требуется больше человеко-времени. Когда есть ТЗ, разработчики разрабатывают, тестировщики тестируют, тех. писатели описывают, причем сходу. А без ТЗ они все проделывают работу по составлению ТЗ для себя каждый раз. И менеджер работает больше.
Мне тут начальник сообщает.
1. Размещать надо не на весу, а всей поверхностью лежать абсолютно ровно, чтобы под собственным весом ничего никуда не сместилось.
2. Размещать надо над тарелочкой с солью (или песочком). Соль должна быть равномерно насыпана, разровненной быть.
3. Для разных плат температура разная (nvidia чуть побольше, radeon чуть поменьше). И 30 минут — это очень много (10-15 минут должно хватить). Второй вариант правильный.
4. Надо очень-очень медленно остужать.
5. Суть всего действия в том, что шарики BGA(Ball Grid Array — тип компоновки)-контактов расплавляются, и те шарики, которые были нарушены от разогревов-охлаждений, должны прийти к заводским геометрическим формам (для этого и надо очень-очень медленно остужать). Бывает, что и в самом чипе (хотя это никем не доказано) восстанавливаются связи.
О доведении до конца. По-моему, не зависит это от Agile, RUP, или что-нибудь еще, или Waterfall даже.
Просто следует
* Хорошо представлять себе самому конец проекта,
* Чтобы конец проекта хорошо себе представляли Заказчик, команда, и другие «стейкхолдеры».
По-моему, это необходимо и достаточно для завершения проекта. Хорошая практика — это прямо в ТЗ, договоре, уставе у кого он есть писать, что является условием окончания — 0 критических дефектов, не более 3 некритических (как пример), всё установлено там-то и там-то, подписанный акт, оплата.
Самый лучший service desk, пока не идеальный, как мне видится,
1. Должен соответствовать ITIL, начиная от поддержки процессов управления инцидентами и проблемами, заканчивая подсчетом метрик,
2. Должен обладать хорошим интерфейсом. Потому что это слабое звено большинства решений. При заведении инцидента например, нужно вводить множество полей, так что должны быть шаблончики. Ну и еще по мелочи должны быть подобные решения для ускорения работы операторов. Интерфейс должен быть и для заявителей.
На мой взгляд, в матрице (сильной, слабой, не так важно), менеджером работать лучше, чем напрямую с командой. Работал и так и так. Мне нравится то, что за техническую сторону (качество работ) в матрице несет ответственность в том числе и функциональный руководитель. Не за качество продукта, а за качество исполнения, а также еще за некоторые технические вопросы (обеспечения). Это снимает некоторую нагрузку, и можно более плотно сосредотачиваться на продукте, а не на процессе производства продукта (хотя это немаловажно, так как процесс определяет результат, контроль процесса разделяется между несколькими менеджерами).
Странно, откуда такая проблема. Под WinCE 4.2+ sqlite отлично работает с русским текстом, в том числе и с like 'Перемещение%'. Версия 3.7.4. Правда под WinCE используется только Unicode двухбайтовый. Мне удается даже на сервере генерировать sqlite-базу в UTF-8 и в UTF-16 отлично её открывать и работать с ней и русским текстом в ней (даже не имея на девайсе русской локали), передав её по сети.
Возможно работа с sqlite только в UTF-16 решает проблему?
Метрики — это действительно самое интересное. Особенно когда они привязаны к финансам. Это самое полезное в заварушке — в результате видеть, как подросший бизнес создает деньги.
Сотрудникам это и вправду может не очень нравиться — так что должны быть и им какие-то бенефиты. Не поделитесь, какие нашлись?
Может и еще раз выпустить. Может выкупить свои акции обратно (это считается хорошим признаком). Пока компания не банкрот — акции имеют силу.
Бывают кстати разные акции (обычные, привилегированные — которые не дают права на управление).
Боюсь, нескоро сподоблюсь на написание статьи ввиду текущей загруженности, поэтому пока дам две ссылки. Эту и эту.
Суть вкратце сводится к тому, что риск — это потенциально возможное уменьшение (некоторые говорят и увеличение, но я так не рассматривал этот вопрос) чистых доходов. Собственно для рисков можно выделить два основных метода — это идентификация рисков, и обсчет (качественный или количественный).
Как идентифицировать риски — некоторые составляют реестры (это работает в случае корпоративных проектов), либо же можно «проходом от обратного»: смотрим наилучший вариант развития событий, и спрашиваем себя, а что если вдруг то-то и то-то не сработает. Касательно ИТ — основные риски это риски недофинансирования, ухода ключевых сотрудников, малых продаж, потери кода (такое бывает на самом деле!), затягивание оплат, форс-мажоры (хотя это обычно рассматривают отдельно в договорах), затягивание сроков и удорожание разработки (недооценка).
PMBoK рекомендует для каждого риска разработать стратегию реагирования (можно проактивную, можно реактивную). В зависимости от выбранной стратегии, необходимо менять параметры проекта. Например закладывать резерв, менять порядок и/или сроки старта работ.
Учет рисков в ставке дисконтирования возможен на мой взгляд не для проектных рисков, а для рисков, связанных со средой инвестирования — т.е. для общего инвест. климата (например, весь бизнес в России более рискован чем в Европе например) страны, отрасли.
На мой взгляд основной способ учесть риски — добавить рисковые элементы в проект. Например, статью риск недопродаж, и моделировать уже этот риск, включая потоки от неё в расчет проекта (т.е. мы по сути добавляем в проект элемент-источник риска). Т.е. необходимо рассмотреть проект как систему.
Методы анализа рисков проектов, такие как точка безубыточности, анализ чувствительности, имитационное моделирование (много-много анализов чувствительности) — схожи по применению. Они показывают рискованность проекта самого по себе. Если мы видим, что изменение какого-то показателя (для ИТ это часто стоимость разработки, которая может увеличиться до 3-х раз) очень сильно влияет на показатели эффективности проекта — проект надо переделывать.
Я наверное очень абстрактно выразился, но главное — это идентифицировать риски. Как-то как-нибудь замоделировать уже не их можно, на основе той же теории вероятностей («пусть каждый десятый клиент не оплачивает заказ, тогда влияние риска недоплат составляет за год N рублей»).
Насчет аналогий, пробовал на одном интернет-сервисе… впрочем там и бизнес-модель была слизана.
План — и есть дорожная карта, я не говорил обратного. Но он включает прогноз, планирование его включает.
Точка безубыточности — зависит от разделения на постоянные/переменные. «Настоящая» (о который вы говорите) точка по факту которая — не зависит, но как найти вот то самое разбиение, чтобы она — точка — была «настоящей» — это целый вопрос. Даже стат. методы в этом не работают, говорю потому что использовал для крупного промышленного производства.
И да, забыл добавить. Одна из мыслей этого поста, что именно бизнес-модель (и ничто иное) определяет денежные потоки. А бизнес-модель включает в себя маркетинговое предложение.
Согласен, с одним лишь уточнением — цифры вымышленные, и пример — первое что в голову пришло. Да, витрина, да, производство.
Что касается прогноза продаж — особенно для новых продуктов — это очень сложно, я знаю. Однако практически на любой продукт найдется заменитель, и можно смотреть по аналогии. Совсем без прогноза продаж нельзя планировать. Невозможно я бы сказал. У крутого бизнеса есть такие вещи, как маркетинговый анализ, фокус-группы, и прочее. У малого — надежда и… опрос среди знакомых :) Касательно точки безубыточности скажу, что опасная это штука, так как зависит от того, как будут поделены затраты. Это инструмент хоть на вид и простой, но для, я считаю, ну очень продвинутых.
Методы не поменялись, да и не должны были бы, дисконтирование в его нынешнем виде придумали лет (кажется) 100 назад. Насчет шарообразного — ну кому как. Меня этот подход выручал, я говорю про минимальное моделирование, прежде чем начинать — посмотреть варианты, и сравнить их по критерию. Эти методы, хоть и не поменялись, толком мало где применяются. Конечно, можно говорить, что всё плохо прогнозируемо… и все дело в риске, и что ИТ не такой, но кто тогда будет в него вкладываться? Только венчуры, а этого мало я считаю. ИТ все таки уже зреет до того, чтобы стать промышленностью, а не ремеслом.
Я говорю про Excel ввиду его доступности. Есть и (гораздо) более специализированные решения для работы с инвест. проектами. Как на базе Excel, так и нет.
В MS Project с формулами и переменными работать сложнее, но сама работа с проектами там конечно же нагляднее. Хотя и в Excel можно нарисовать диаграмму Гантта :)
Мое мнение — MS Project удобен для управления проектом (по окончательному бюджету), для предварительного анализа можно пользоваться и Excel, в нём быстрее и проще исправлять на мой взгляд.
Мне видится, что на работу без ТЗ требуется больше человеко-времени. Когда есть ТЗ, разработчики разрабатывают, тестировщики тестируют, тех. писатели описывают, причем сходу. А без ТЗ они все проделывают работу по составлению ТЗ для себя каждый раз. И менеджер работает больше.
1. Размещать надо не на весу, а всей поверхностью лежать абсолютно ровно, чтобы под собственным весом ничего никуда не сместилось.
2. Размещать надо над тарелочкой с солью (или песочком). Соль должна быть равномерно насыпана, разровненной быть.
3. Для разных плат температура разная (nvidia чуть побольше, radeon чуть поменьше). И 30 минут — это очень много (10-15 минут должно хватить). Второй вариант правильный.
4. Надо очень-очень медленно остужать.
5. Суть всего действия в том, что шарики BGA(Ball Grid Array — тип компоновки)-контактов расплавляются, и те шарики, которые были нарушены от разогревов-охлаждений, должны прийти к заводским геометрическим формам (для этого и надо очень-очень медленно остужать). Бывает, что и в самом чипе (хотя это никем не доказано) восстанавливаются связи.
Просто следует
* Хорошо представлять себе самому конец проекта,
* Чтобы конец проекта хорошо себе представляли Заказчик, команда, и другие «стейкхолдеры».
По-моему, это необходимо и достаточно для завершения проекта. Хорошая практика — это прямо в ТЗ, договоре, уставе у кого он есть писать, что является условием окончания — 0 критических дефектов, не более 3 некритических (как пример), всё установлено там-то и там-то, подписанный акт, оплата.
Хотелось бы, чтобы было много записей.
Единственное, не очень понял — nearby — это насколько near? В пределах города или как?
1. Должен соответствовать ITIL, начиная от поддержки процессов управления инцидентами и проблемами, заканчивая подсчетом метрик,
2. Должен обладать хорошим интерфейсом. Потому что это слабое звено большинства решений. При заведении инцидента например, нужно вводить множество полей, так что должны быть шаблончики. Ну и еще по мелочи должны быть подобные решения для ускорения работы операторов. Интерфейс должен быть и для заявителей.
Возможно работа с sqlite только в UTF-16 решает проблему?
Сотрудникам это и вправду может не очень нравиться — так что должны быть и им какие-то бенефиты. Не поделитесь, какие нашлись?
Бывают кстати разные акции (обычные, привилегированные — которые не дают права на управление).
Суть вкратце сводится к тому, что риск — это потенциально возможное уменьшение (некоторые говорят и увеличение, но я так не рассматривал этот вопрос) чистых доходов. Собственно для рисков можно выделить два основных метода — это идентификация рисков, и обсчет (качественный или количественный).
Как идентифицировать риски — некоторые составляют реестры (это работает в случае корпоративных проектов), либо же можно «проходом от обратного»: смотрим наилучший вариант развития событий, и спрашиваем себя, а что если вдруг то-то и то-то не сработает. Касательно ИТ — основные риски это риски недофинансирования, ухода ключевых сотрудников, малых продаж, потери кода (такое бывает на самом деле!), затягивание оплат, форс-мажоры (хотя это обычно рассматривают отдельно в договорах), затягивание сроков и удорожание разработки (недооценка).
PMBoK рекомендует для каждого риска разработать стратегию реагирования (можно проактивную, можно реактивную). В зависимости от выбранной стратегии, необходимо менять параметры проекта. Например закладывать резерв, менять порядок и/или сроки старта работ.
Учет рисков в ставке дисконтирования возможен на мой взгляд не для проектных рисков, а для рисков, связанных со средой инвестирования — т.е. для общего инвест. климата (например, весь бизнес в России более рискован чем в Европе например) страны, отрасли.
На мой взгляд основной способ учесть риски — добавить рисковые элементы в проект. Например, статью риск недопродаж, и моделировать уже этот риск, включая потоки от неё в расчет проекта (т.е. мы по сути добавляем в проект элемент-источник риска). Т.е. необходимо рассмотреть проект как систему.
Методы анализа рисков проектов, такие как точка безубыточности, анализ чувствительности, имитационное моделирование (много-много анализов чувствительности) — схожи по применению. Они показывают рискованность проекта самого по себе. Если мы видим, что изменение какого-то показателя (для ИТ это часто стоимость разработки, которая может увеличиться до 3-х раз) очень сильно влияет на показатели эффективности проекта — проект надо переделывать.
Я наверное очень абстрактно выразился, но главное — это идентифицировать риски. Как-то как-нибудь замоделировать уже не их можно, на основе той же теории вероятностей («пусть каждый десятый клиент не оплачивает заказ, тогда влияние риска недоплат составляет за год N рублей»).
План — и есть дорожная карта, я не говорил обратного. Но он включает прогноз, планирование его включает.
Точка безубыточности — зависит от разделения на постоянные/переменные. «Настоящая» (о который вы говорите) точка по факту которая — не зависит, но как найти вот то самое разбиение, чтобы она — точка — была «настоящей» — это целый вопрос. Даже стат. методы в этом не работают, говорю потому что использовал для крупного промышленного производства.
Что касается прогноза продаж — особенно для новых продуктов — это очень сложно, я знаю. Однако практически на любой продукт найдется заменитель, и можно смотреть по аналогии. Совсем без прогноза продаж нельзя планировать. Невозможно я бы сказал. У крутого бизнеса есть такие вещи, как маркетинговый анализ, фокус-группы, и прочее. У малого — надежда и… опрос среди знакомых :) Касательно точки безубыточности скажу, что опасная это штука, так как зависит от того, как будут поделены затраты. Это инструмент хоть на вид и простой, но для, я считаю, ну очень продвинутых.
Методы не поменялись, да и не должны были бы, дисконтирование в его нынешнем виде придумали лет (кажется) 100 назад. Насчет шарообразного — ну кому как. Меня этот подход выручал, я говорю про минимальное моделирование, прежде чем начинать — посмотреть варианты, и сравнить их по критерию. Эти методы, хоть и не поменялись, толком мало где применяются. Конечно, можно говорить, что всё плохо прогнозируемо… и все дело в риске, и что ИТ не такой, но кто тогда будет в него вкладываться? Только венчуры, а этого мало я считаю. ИТ все таки уже зреет до того, чтобы стать промышленностью, а не ремеслом.
В MS Project с формулами и переменными работать сложнее, но сама работа с проектами там конечно же нагляднее. Хотя и в Excel можно нарисовать диаграмму Гантта :)
Мое мнение — MS Project удобен для управления проектом (по окончательному бюджету), для предварительного анализа можно пользоваться и Excel, в нём быстрее и проще исправлять на мой взгляд.