Vov Vov

Как ни парадоксально это звучит, но улучшение прослеживаемости требований не приведёт к улучшению качества. - это скажем так, моё утверждение :)

Сама концепция написания АЗ и ТЗ утратила актуальность. Процессы согласования, утверждения и планирования отнимают слишком много бесценного и дорого времени. Мой рецепт не претендует на универсальность, но для моих задач он работал и работает прекрасно. Метод был уже описан западными авторами, но, как мы все понимаем, методология в чистом виде нигде не применяется, а всегда добавляются свои специфические примеси или наоборот, что-то убирается. Данный метод можно назвать "Быстрое прототипирование", предпосылками для такого метода является, то что люди в сотни раз быстрее воспринимают визуальные (графические) концепции, чем текстовые описания, таким образом, если делать быстрые графические прототипы (1-2 дня) и запускать цепочку согласования, то обратную связь можно получить за те же 1-2 дня, далее 1 день на агрегацию и подготовку короткого описания 1-3 страницы, вместо 15 как раньше. После согласования, этап подготовки спецификации для разработчиков (1 день).
Также привествуются создание универсальных моделей прототипов, например, которые описывают некоторые стандартные особенности без привязки в функциональности, таким образом на этапе тестирования и подготовки тест-кейсов/тест-планов по конкретной функциональности учитывают "стандартные" поведенческие особенности, что приводит к общему улучшению качества.
Ещё очень эффективным инструментом лечения всяких болячек в софте является следование практикам ISO 9001 в частности сбор обратной связи с клиентов, проведение советов по качеству, надзор внутри организации за процессами (на сколько качественно они выполняются и т.п.). Это глобальная тема, но при желании можно её осилить.

P.S. Для создания быстрых прототипов можно использовать разный софт, но мне больше все полюбился Balsamiq. Для описания требований есть ещё Rational RequisitePro (www.caseclub.ru/articles/requisite.html), более глобальный инструмент с моделированием процессов Aris, но я считаю что это уже олдскул и надо решать эти задачи вышеописанным методом.
P.S. Чтобы было понимание всё о чём я писал работало на численности разработчиков от 15 до 120, а то мало ли у Вас там тысячи :)

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

Я читал старую, но достаточно интересную книжку "Как пасти котов". Ну и про Agile в принципе можно что угодно почитать, но как говорится одно дело книжки другое дело практика.

Если ты из Мск могу порекомендовать свой очный курс: propercourse.ru/courses/1

Добрый день, МП - это достаточно ответственная работа и человеку без опыта я бы её поручать не стал, таким образом, очень маловероятно что Вас могут взять в другую компанию на эту позицию. Могут взять помощником менеджера или администратором проекта. Что я могу порекомендовать:
1. Попробовать вырасти в текущей компании до желаемой позиции., если не получается то:
2. Работая в компании пройти профильные курсы по управлению разработкой или управлению проектами (очные или лучше магистратуру).
3. Попробовать себя в Open Source разработке или волонтёрстве под условием открытия исходного кода и процесса разработки, например, от начала и до конца разработки вести все дела в GitHub или аналоге.
4. Найти единомышленников и подключить их к проекту.
В последние несколько лет я замечаю тенденцию, что рынок уже не очень жаждет МП, а больше склоняется к кросс-функциональным сотрудникам, т.е. ты МП, но ещё и программер/аналитик или тестировщик. Что касается Agile-практик, то на мой взгляд этим уже никого не купишь, ключевой вопрос не в том, что у Вас был Agile на прошлой работе, а в том, что Вы можете его построить тут с новой командой. И как раз тут 3,4 пункт может сыграть ключевую роль.
Будут вопросы пишите, контакты в профиле.

Я использую Redmine + дополнительные поля и трекеры.

Добрый день, то что Вы пишите, это некоторый частный случай разработки ПО в соответствии с принятой методологией в компании. Я бы не решился писать софт "полного цикла" в вашем представлении. Лучше выбирать специализированные продукты и потом их интегрировать через шину или другими доступными способами.

P.S. Извините, что это не ответ на Ваш вопрос, а скорее критика самого вопроса :)

Конкретно по пунктам:
1. Идею можно запатентовать в качестве полезной модели - это пожалуйста. Например, в РФ, но её патенты не совсем действуют в других странах, с патентами США несколько лучше. Расходы охрану инт. собственности в различных юрисдикциях будут от 100 000 долларов.

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

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

Ваш вопрос описывает типичный кризис среднего возраста, когда понимаешь, что ты уже догорел в той сфере, где ты сейчас работаешь. Я могу ошибаться быть слишком жестоким в оценках, но пусть это будет моим личным мнением. Так вот, то что Вы хотите уходить в программирование - это конечно замечательно, только ради чего? Вы отдаёте себе отчёт в том, что будет в 10 раз тяжелее осилить эту тему чем Вы представляете? Уверены ли Вы в том, что спустя 1-1,5-2 года усилий Вас просто не будут брать выше джуниора на зп в 3 раза меньшую чем Вы получаете сейчас? Ваша семья безусловно Вас поддержит в начинаниях, например, занятий по вечерам и т.п., но это не может продолжаться долго и как мне кажется у Вас просто не хватит мотивации, чтобы довести это дело до конца. Технологии о которых Вы говорите, как мне кажется не являются предметом Вашей цели, а просто ближайшими инструментами, для достижения её. Вообщем я желаю Вам успеха как бы там не было и надеюсь, что своим комментарием породил в Вас несколько "правильных" вопросов о смысле данного начинания.

Написание технических заданий - это прежде всего навык самого человека, который надо развивать. Вы не правильно ставите вопрос. Курсы Вас не научат писать ТЗ. Но вы сами можете себя научить писать выдающиеся технические задания. Почитайте литературу по анализу требований или Babok, если есть возможность. Проблема ТЗ кроется в трёх вещах: 1. ТЗ - пишется для заказчиков, программистов это бесит. 2. ТЗ - реализовывается на 70-80-90% - это бесит всех. 3. Ресурсы на написание ТЗ, ресурсы проекта, технический долг проекта.
Т.е. хорошее ТЗ - это всегда баланс между интересами всех участников проекта. А стандарты по которым пишется ТЗ - это формальность.

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

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

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

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

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

Роман, добрый день. Давайте разложим по полочкам всё что Вы написали в вопросе:

1. Пример сметы проекта.

2. Простой план (не фин модель).

3. Cashflow, KPI, ROI.

Для пунктов 1-2 используйте Канву бизнес-модели. Для Стартапа деньги важны, но ещё больше важно целостное понимание того что Вы собираетесь делать включая работу с поставщиками, логистику и прочее. Потому что подстава будет там где Вы её совсем не ждёте.

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