Добрый день. Раньше работал во франче где были менеджеры проектов. Сейчас работаю на фиксе, в нет менеджеров проектов. У меня есть руководители отдела 1С и руководитель всего ИТ отдела, но они не менеджеры проектов. У меня скоро будет небольшой проект по написанию подсистемы. Подсистема для производства в УПП, что там будет пока не знаю.
У меня ряд вопросов, может, подскажите, пожалуйста:
1)Как грамотно собрать требования за наименьшее время?
2)Как выстроить архитектуру подсистемы, так чтобы она была достаточно универсальной, но при этом не сильно проседала в производительности.
3)Где фиксировать требования заказчиков и в каком формате, чтобы я мог работать по этим требования и они были понятно и просто изложены.
4)Как оценить все возможные риски?
5)Как лучше взаимодействовать с заказчиком? То есть писать большие письма, где будет все и сразу, писать маленькие письма, которые просто читать, но из-за объема писем в них потом будет трудно разобраться? Или может вообще общаться с заказчиком по скайпу и выяснять все вопросы на прямую?
Вроде, больше нет вопросов, буду признателен, если подскажите или скинете статьи, в которых вот это все описано

Не уходите)

(0)
))) РП - это далеко не то что ты описал, как минимум у тебя нет бюджета
у тебя какая модел внедрения (запуска) будет?
Каскад или водопад?


1) иди и говорить, при этом лучше сразу задавать "каверзные" вопросы, чтоб потом не переделывать
2) тебе надо ЕРП2/КА2/УТ11 посмотреть как работают - и с таким же подходом строить свое "новое"
3)советую сразу вести доску заявок (BugBoard) в ней и зарегиш сам все требования, классфикация минимальная:
  - первичное требование
  - Ошибка
  - Расширение функционала
дополняешь классвификацией критичности все " Кретично/ не критично"
4) почитай выдержки из PMI - PMBook - про управления рисками
5) проект внутренний лучшеделать маленькие письма после пунка 1, которые фиксируют требования. и обезательно надо строить предложения так, чтоб не было "двоякого чтения"


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

тебе надо потом по списку определить зависимости ... и проставить их ... найти самое "узкое" требования, без которого большенство других доработок будет стоить. короч самое узкое место делаешь первое + правило 20/80 % никто не отменял.
определи Вехи проекта и поставь на них сроки. и потом это все согласуй.

(1)+(2)
будут
вопросы пиши в другие средства связи (скайп к примеру), так как тут очень редко

от создателей Как стать хорошим архитектором своей системы?

(0) по пунктам
1. не бывает какого-то такое чеклиста, кторый скачал из интернетов, проставил галки и получил корректное техзадание.
2. никак, если ты не умеешь видеть будущее.
3. в системе учета задач. Любой удобной тебе.
4. никак, если ты не умеешь видеть будущее.
5. общаться очно, результаты общения фиксировать буквами как угодно

волшебного какого-то howto нет. Это с опытом приходит и у каждого свое. Или - не приходит.

(2) Спасибо больше, на счет модели внедрения не знаю. Очень помогли с Багбордом и тем, что надо найти узкое место. Звонить вам не буду, ибо не хочу тратить ваше время.
Еще раз спасибо за ответ, пойду прочитаю что такое PMI - PMBook
(4) А это тут при чем?) Я так и не стал, если что( Посовеовался с колелгами, сказали что мне надо больше опыта. Да и не при чем тут эта тема

(6) при том, что это один и тот же вопрос. И ответ будет один и тот же.

требования выявляются посредством последовательного задавания вопросов "зачем?" и "как вы в результате поймете, что получили то, что вы хотели?"

+(8) в вечном цикле

(8) Ну, от запросов в цикле эе надо избавляться, не лучше тогда сделать один здоровнный запрос к заказчику?)) (7) Нет, там я хотел научиться делать хорошую архтектуру, а тут мне надо всести целый проект, это разные вещи, хотя 1 включается в другое

(0)

1.
1.1. Идентифицировать как можно раньше:
    а) заинтересованных в результате ЛПР
    б) носителей знаний предметной области и процессов (обычно это непосредстванные участники)
1.2. Встретиться с а), обсудить и придумать мотивацию для б). В идеале еще должна быть совместная встреча с а) и б) с раздачей указаний.
1.3. Интервьюировать б)
1.4. Систематизировать, выявить противоречия. Повторно встерчаться с б) для их разрешения.

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

3. Если с требованиями будешь работать только ты, то как угодно, формат не важен. Если не только, то придется попотеть, и желательно придерживаться какого-нибудь стандарта.

4. Это невозможно. Тут только опыт помогает.

5. Не очень понятен вопрос. Общаться по скайпу или по почте - это как вы договоритесь, как удобнее обоим сторонам.

(11)"Общаться по скайпу или по почте - это как вы договоритесь, как удобнее обоим сторонам."

ИМХО текстовая почта стороне Исполнителя конструктивнее, так как если даже общение по скайпу записывать, то с аудиоматериалом затем работать сложнее и дольше, чем с текстовым, а отекстование аудиоматериала опять же отнимает время. по сути речь придет примерно об этом, так как что врачам нужно голос в текст переводить, что внедренцам.
https://www.speechpro.ru/media/news/01-12-2016-1
"Специалисты ЦРТ разрабатывают программу, которая сможет переводить голос в буквы. Благодаря ей медикам не надо будет тратить много времени на заполнение документов вручную. Программа уже с успехом тестируется в Петербурге, правда в одной поликлинике, а также в клинической больнице Казани."

(10)"не лучше тогда сделать один здоровнный запрос к заказчику?))"

создайте, но за ним все-равно последует череда более мелких.

(11) (12) Большое спасибо. Как много хороших ответов в ветке. Кстати, по той ветке что я сздавал про архитектуур не было таких хороших ответов. Может, здесь одни РПшники сидят?))

(10)
"здоровенный вопрос" - не отразит реально происходящего  - проще идти от "общего" к "частному" (последнее достаточно часто  выявляет не согласованность в "Общем")

по факту ты не будешь вести в проект (по крайней мере как я это понимаю) - ты будешь программистом - консультантом/аналитиком. и не более. так как до другого у тебя не дойдут руки

(11)
пункт 2  - вот не согласен, надо сразу предвидеть "параметрические" вещи в "новье", но это будет все зависеть от того насколько хорошо выполнен пункт1. т.е. надо заложить в систему запас "по гибкости".
пунтк 4 - с чего не возможно то, базовые риски всегда оценить можно
( для примера два ( причем вот они тут будут самые критичные):
  - не компетентность/ не хватка времени у заказчика - результат ожидание не соответствует результату или срыв сроков
  - не хватка времени у исполнителя - срыв сроков проекта

(14) я вот что-то сомневаюсь что на мисте тусуют РП ( у них тупо времени нет)))

(15) ну это вопрос определения - "кто такой РП и с чем его едят"

(14) а что за ветка "про архитектуру" ?

(15) "здоровенный вопрос" - не отразит реально происходящего  ок, понял
ты будешь программистом - консультантом/аналитиком. и не более.
Я еще сроки буду указывать, на все. В общем, я незнаю своб роль, мне просто надо выполнить проект

(17) Вот тут про ветку Лефмихалыч вспомнил (4)

(14) есть же доступ к сайту ИТС? Пользуешься?
Там прямо со стартовой есть ссыль на видео-ролик относительно ТБР. И оно там из множества небольших кусочков.

Я так для себя понимаю, что размер проекта "большой" или "маленький" как раз и определяет потребность в выделенном позиционировании РП. На небольших проектах труднее обосновать, что такая позиция необходима и, тем более, труднее показать позицию Архитектора Системы (нарочно указываю с капса, чтоб выделить понятие)

(19) пойду гляну, что там наговорили

(20) К ИТСу есть, иногда пользуюсь. А ТРБ это типовая по проектам? Я вбил в поиск ТРБ - у меня тоолько что-то про налоги выдало "Гарант. Налоги, бухгалтерский учет, предпринимательство"

(14) добавлю еще к (15) по рискам -  у тебя ,в реальности, только вопрос сроков и мотивации (последнее чтоб саботажа не было). ни бюджета ни субподряда, у тяб все более менее норм по рискам, главное вехи накидать корректно
(16) ну да,  все разное в это понятие вкладывают - а еще чаще менеджера  и руководителя проекта путают.

(18) совет тебе ... запустись в итерационной модели доработок, только первой итерации отведи на разработку пару недель, а остальные будут по неделе - это опитимально : два дня тербования собираешь 2 дня кодишь, + 1 (планирования + туда-суда что-то не предвиденное) -

(22) Это как по СКРАМу? Надеюсь, пользователи согласятся так вести работу, наверное, так будет лучше

(21) ТБР - это Технология быстрого внедрения. не советую ее читать, так как человек который ее писал (точно не помню , Бессонов Олег помоему)  сам с треском провалил проект, его сняли ( я был на стороне заказчика). SCRUM читать надо )) это сила

(23) все верно. только тут один человек ))))
а подругому я уже не получится... так как стабильность будет и заказчик видеть будет результат оперативно.
+ от себя еще добавлю большие проекты на ЕРП2 только так и запускать можно,

(15) > надо сразу предвидеть "параметрические" вещи в "новье", но это будет все зависеть от того насколько хорошо выполнен пункт1. т.е. надо заложить в систему запас "по гибкости"

Я раньше тоже пытался всегда так делать. Потом понял, что более чем в половине случаев мои "предвидения" не оправдываются. А время было потрачено (за счет чего-то другого). Теперь я допускаю обобщения только, если это почти ничего не стоит.

Хорошая цитата в тему внизу этой страницы:
"Требовать и эффективности, и гибкости от одной и той же программы — все равно, что искать очаровательную и скромную жену... по-видимому, нам следует остановиться на чем-то одном из двух."
Фредерик Брукс-младший

(24) там не так много и просмотр чужого опыта, даже если кто-то признаЕт этот опыт провальным, тем более, если провальным - позволит не изобретать велосипеды и учиться на чужих ошибках.

Не думаю, что там все правильно, но по крайней мере наглядно и систематизирована сама проблема. Может быть это просто версия переложения СКРАМ в терминах русского языка.

(23) а вот возьми и перечитай ветку Удобная реализация конечных автоматов в 1С8
рассматривая ее как частный пример как раз небольшого проекта для доработки в производстве из УПП :)

(26) а я так делаю всегда - но, я думаю, тут уже больше опыт сказывается, так как знаешь где грабли .даже иногда с консультантами ходишь и задаешь вопросы "не удобные" заказчику, но при этом по реальным примерам  ( ну или хотяб основываясь не реальном опыте) и в конечном итоге делают как ты предложил.  я сам технич РП  или технический/системный архитектор просто. и периодически ТЗ возвращаю консультантам на изменения.
(24) плохой опыт всегда более поучительный, но только когда он твой. (такие уж мы человеки ))))  - ну чужом не учимся )
а читать умные книги от человека который "провалился" - не считаю нужным, так как не будет серьезного восприятия того что там он написал ))
я сам не читал но там Agile, и точно не SCRUM , но сходства есть по рассказам.
мне просто в SCRUM нравятся:
спринт ( с внутр квантованием) - четкие рамки
Митинг - быстро и по существу + все сразу вкурсе всего.
Аукцион (подстегивает сотрудников - соревнования + тотализатор твоего рабочего времени)

За тарелку супа на фикси можно заниматься всем, кроме самого проекта. ТС не озвучил базовые требования к своему "небольшому проекту". Любая подобная работа - это бесконечная череда текущих задач, которые некоторые называют гордым словом Проект.

скрам - к херам. Чтобы его практиковать в каком-то проекте, надо сначала набить разных шишек и состояться, как разработчик на столько, чтобы вопросов типа сабжа не было.

(30) Если задачи связаны какой-то общей целью или хотя бы последовательностью (а цель достигается последней задачей), то это конечно же проект. А ты под "кучей мелких текущих задач" что имел в виду - латание дыр и реализация свистелок-перделок? :)

(30) -  это точно
в конечно итоге нескончаемый процесс, ой проект))))

(31) - вообще не прав, в него и новичков затаскивают чтоб быстрее натаскивались. но начинать тяжело, особенно 1Совцам.

(33) ты ветку читал вообще? В существующую скрам-команду можно добавлять новичка, базару, как грица, ноль. Но с объемом знаний и опытом автора организовать скрам команду вариантов вообще нет. Совсем. Вообще. Рекомендовать ему использовать скрам для решения задачи из топика - тупость. Получится срам в чистом виде.

(32) цель всегда одна и состоит из трех половин:
1. Сделать всё
2. Все должно быть сделано хорошо
3. Хорошо должно пользователю делаться само, автоматически

(34) канечно читал и писал в (22) даже по этому поводу. скрама у него точно не будет ( он и мастер и выступающий на митинге)  так как он ОДИН )))  - ахахахаха
я ему говорю в итерационную модель обязательно уйти, ну и попилить время как удобнее день сбор требований, день кодинга, повтор, и день на всякое какашки и подтянуть хвосты, и распланировать след.неделю

(36) к итерациям - плюс стопятьсот.
Да, скрама не будет потому, что для него нужны опыт, команда, стальные яйца - в обязательном порядке всё это вместе.

(37) ++++