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

Про метод трех гвоздей слышал? А все остальное, если умеешь программировать, имхо лишнее.

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

(0) Лучше всего поработать в компании, в которой эти вещи внедрены.
Ну или хотя бы попытаться получить чьи-нить документы по проекту.
Но второе — жалкое подобие первого конечно.
Вообще, работа по проектам, как правило, внедряется кровью фирмы и сотрудников.

(3) или без постановки глобальных целей и сроков вырождается в работу по техзаданиям в свободное от поддержки время

(1) Правило не применимо, т.к. нужен четкий контроль и прозрачность работ, а так же состояний этих работ.

(3) Жаль, но так не получится.
В продолжении спрошу, не сможет ли кто по форумной дружбе сбросить пример проекта или ТЗ? Буду благодарен.

(4) Я разве написал "Если фирма и сотрудники будут исходить кровью в желании внедрить работу по проектам, то будет внедрена работа по проектам"?

(0) http://infostart.ru/public/275471/

(6) Ээээ.... "Пример проекта" - это жестко. Что в Вашем понимании "проект"?

(0) Для начала сделай штук 10 внедрений УПП, без опыта все эти проектные технологии нет смысла изучать.

(9) Ну как что. Координаты клиента, видимо :))

(10) Я в условиях этого кризиса, уже ввел заявку на внешний отчет, ТЗ на отчет, а вы говорите о внедрении на честном слове.

мне ваш клиент не нужен. Со своими бы справиться. А вот пример не повредил бы. Хотя бы шаблон проекта, что бы понять, что как и почему.

(12) у тебя это не проекты, а задачи
(13) для чего тебе шаблон проекта для внешнего отчета?

(14) У меня и проекты, и подпроекты, и даже задачи.

(15) да хрень у тебя это, а не проекты

Шаблон проекта «Внедрение информационной системы департаментом информационных технологий предприятия» в формате Microsoft Project 2007/2003

http://www.pmprofy.ru/content/rus/174/1749-article.asp

х.з. что это. яндекс на похожие как у (0) слова ссылку выдал :)

(16) А можно Вас попросить удалиться из обсуждения, если вы продолжите столь резкую критику? Просто я не в настроении вступать с вами в полемику, мне надо решить вопрос, или получить помощь адекватных людей на форуме.

и вообще http://yandex.ru/yandsearch?lr=2&text=шаблон+проекта+по+внедрению+ИС

(17) (20) Спасибо!

ну хоть кого то научил яндексом пользоваться

(22) И то верно.

А кроме microsoft project  кто что использует?

(0) Эффективнее всего - это взять в штат человека, который уже работал по такой системе. Например, меня.

За 150 тысяч в месяц я готов у вас работать.

(25) за 150 000 я готов это изучить и лишить Вас, уважаемый работы демпенганув до 120 000 в размере ЗП.

1С:Управление проектным офисом - никто не пробовал?

(26) Можно и так. Но...
Вместо того, чтобы уже начать работать, вы будете
1. терять время на обучении.
2. терять время (и деньги) на косяках при обучении.

Моё дело предложить.

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

Не зря же говорят: в умелых руках - и х.. - балалайка!

(26) Этому нельзя научиться за 150 т.р. Это опыт, умноженный на годы.

(27) Вы считаете, что если Вам дать Макларен, то Вы сразу станете Шумахером?

Внедряй!
http://www.youtube.com/watch?v=-uGdaKFboHo

http://www.youtube.com/watch?v=dsX1zfwtR2I

(0) ТЗ - теоретически вещь нужная, практически мне часто приходится формализовать требования на лету и делать абы как, чтобы потом переделать по-человечески. Просто не имея под рукой чего-то рабочего идти дальше бывает очень сложно.
Проекты - это еще одна административная надстройка, нужна разве что для организации поточной работы и выноса на посредника формирования тех же ТЗ или общения с клиентом. Если предполагается что писать и согласовывать и программировать по ТЗ будет один человек, да еще с клиентом общаться и документы выставлять на оплату - то это все пустая трата времени этого человека и делание его виноватым в любом косяке с клиентом.

(32) так подумаешь - проекты и ТЗ сплошное зло, но все это зло осваивают и дальше развиваются.

тс, вам теперь нужен
технолог
бизнес-аналитик
тестировщик

(34) в (30) все описанно как тестировать

(33) Очень зависит от квалификации программиста - если требуется наставник и у РП неплохой опыт - ага, тут дело пойдет. Если прог сам себе начальник и РПшника "за пояс заткнет" по знаниям, то РП тут часто может мешаться просто как лишний начальник.

(36) Во втором случае программист ограничен своей производительностью, он сможет еще больше увеличить производительность только за счет уменьшения личного времени. Это просто остановит его рост и заставит  его что делать? правильно, руководить.

(0) "В нашей небольшой организации внедряется работа по проектам и по техническим заданиям"
А цель какая? Чтоб все как у людей?

(38) Для увеличения объемов работ, для улучшения качества работ, для прозрачности работ для заказчика.

(39) Можно было сказать проще: для повышения эффективности.

Как успехи?

(40) Для увеличения объемов работ? выполненных? сомнительно. Качество и прозрачность - да. Объем - нет.

(32)
> часто приходится формализовать требования на лету
> и делать абы как, чтобы потом переделать
фактически, стоимость такой разработки = "формализовать требования" + "делать абы как" + "потом переделать"
если устранить "абы как", то вроде как подешевеет, не ?)
ну и "формализовать требования" = работа РП ?

Бывают и такие ситуации:
1. Разработано ТЗ. Со всеми согласовано, подписано.
2. Разработано ПО по этому ТЗ.
3. Вышли на этап тестирования (рассмотрим ситуацию, когда все сделано оптимально, т.е. все работает быстро и правильно). И тут заказчик выдает "А давайте сюда добавим еще небольшую, но важную шняжку". В результате оказывается, что под эту шняжку нужно "ломать" разработанную структуру.

И приходим к ситуации: "*опа в форточке".

В небольших фирмах нет смысла выделять под РП отдельную штатную единицу. С объемом работ справится и рук.отдела.

Эпиграф к должности РП: корабли лавировали лавировали и не вылавировали.  :)

(43)
> И приходим к ситуации: "*опа в форточке".
Только если по каким-либо причинам выполненный исполнителем объем работ не будут оплачен заказчиком.
Если с оплатой проблем нет, то исполнителю только профит, не ?)

(44) Если мы говорим про "внешних" заказчиков - то да. Чем больше объемы работ - тем больше денег. В данном случае, нужно каждый раз напоминать заказчику за что он платит. И как изменится сумма в зависимости от той или иной "хотелки".

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

(42) Никакой РП есно формализовывать требования не сможет, он вообще разработкой не занимается. И РП тут не наставник. Что дальше? Правильно - обследование  + такой же почти виртуальный функциональный дизайн разработанный тем же прогом либо бизнесс-аналитиком (скорее всего с тем же "абы как"), подписанный, кое как реализованный. При демонстрации вой клиента нам так неудобно, переделка дизайна, пересогласование дизайна. Реализация дизайна в удобном для клиента виде. В этом процессе разработчик чуть больше защищен, но этот процесс никак не дешевле.

(40) Успехи есть. Их много, но недостаточно.

(0) "В нашей небольшой организации внедряется работа по проектам и по техническим заданиям..."

Расскажи мне как это происходит?

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

задание - это описание конечного обьема работ с методикой приемки и проверки результата

проект - это описание конечной цели и требуемых ресурсов.

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

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

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

Это сложно, но можно... например:


1.    Минимальная функциональность – система позволяет пользователям проводить самостоятельно (без сторонней помощи и консультаций) 80% действий по торговым операциям, а именно: поступление, реализация, резервирование, перемещение, печать первичных документов, остальные 20% система позволяет делать или «неудобно», или «нештатно». Система позволяет пользователям получать самостоятельно (без сторонней помощи и консультаций) 50% требуемой им аналитической информации, остальные 50% аналитической информации может быть получена «не штатно», или дописаны механизмы ее получения в приемлемых для бизнеса временных рамках (например, к закрытию квартала).

(48) В нашей организации по сути не было РП, не было много чего, это была типичная фирмочка-франчик. К нам обращались люди, мы делали для них работу. Потом людей и работы стало достаточно для того, что бы мы поняли, что дальше развиться не можем из-за не правильной архитектуры нашей фирмы. Для дальнейшего нам надо было либо систематизировать все процессы в фирме, либо работать по 24 часа в день.

Расписали бизнес процессы нашей работы, утвердили, что работаем через заявки. Т.е. первоочередной документ - заявка от заказчика. На основании заявки идет анализ, что хочет заказчик. Потом составление ТЗ, утверждение, реализация ТЗ, сдача работы. Приемка работ осуществляется по плану описанному в ТЗ.

Схема взлетела. Все нормально. Потом пошли дальше, надо начинать управлять и руководить, для этого нужен контроль над проектами, задачами в рамках проекта и т.д.

Была поставлена цель: развитие организации, для развития необходим контроль качества и контроль работ. Мы должны четко понимать, что мы делаем, для кого, сколько людей работает над проектом и т.д.

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

ps Прошу если есть что добавить, то конструктивно покритиковать.

(52)Выполняете любые хотелки клиентов?

(52) почитай про https://ru.wikipedia.org/wiki/ITIL

http://www.1c.ru/rus/partners/training/uc1/course.jsp?id=257

(51) Сейчас используете какую-нибудь CRM систему?
Для контроля качества работ нужно определиться с показателями, т.е. "оцифровать" вашу работу.
Когда накопите статистику по таким показателям, сможете окинуть взглядом в целом свою деятельность и сделать упор на узкие места.

(53) на стадии Заявки "бред сивой кобылы" отсеиваивается. Мы просто говорим:" Пожалуйста переформулируйте вашу заявку". И не тратим на них время. То что вменяемо, или хотя бы похоже на вменяемость идут в анализ. На стадии анализа отсеивается вторая часть заявок, остальным занимаемся.

(57) А кто отделяет бред сивой кобылы от не бреда?

(57) Считали какой процент обращений, вы отсеиваете?

(55) Спасибо. Думаю мне туды надо, и надо срочно!

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

хотя есть встроеная (самописная) система поручений...

(56) Нет, пока не добрались.
(58) мы и определяем, заказчик присылает заявку и говорит: сделайте отчет в табличной части документа "Отчет о розничных продажах". - Мы пишем что это невозможно и находится за гранью добра и зла. Если он настаивает, то мы говорим что будем думать над отчетом, который ему нужен, но это будет именно отчет, а не измененный документ.

(59) Я думаю что 10% заявок самостоятельно переписываются еще до отправки нам, 2-3% не реализуемы.

(62) Что значит МЫ?? мы это кто? тот  прог, который обслуживает данного клиента.

(64) Да, прогер берет заявку, читает ее и анализирует. Я просто писал в контексте что заявок много прог тоже не один. Мы иногда совещаемся, кому что прислали и как это делать.

(62) ты все-же почитай (51), любые хотелки должны вести к конечной цели, если хотелка ведет к цели ее нужно реолизовывать, если нет - выкинуть...

других критериев оценки необходимости доработок просто нет.... по этому у каждой программы/проекта должна быть обозначена КОНКРЕТНАЯ И ПРАКТИЧЕСКИ ДОСТИЖИМАЯ цель. Если этого нет - то никакие методики управления Вам не помогут....

(65) Интересно.А если у прога настроение херовое или устал сильно, то он может субъективно оценить задачу как "бред сивой кобылы"?

(65) в таком случае, ваше представление о том, что у вас есть некая система, методика-  преувеличение

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

(67) объективная и субъективная реальность

(68) она в стадии эмбриона. Я понимаю, что она не совершенна, и в ней есть косяки. вот и думаю как спроектировать методику эту.

(71) Вы правы. Я задавал вам вопросы, чтобы было понятно, что вам потребуются те, кто будет выполнять функции отсекальщиков бреда, постановщиков, тестировщиков

(71) А как у вас распределены роли между программистами?

(0) что конкретно понимается под "работа по проектам и по техническим заданиям"?

хотя пофиг. В небольшой организации достаточно любого таск манагера (redmine, mantis, 1С:Документоборот) и обязательного учета всех работ в нем

(72) Спасибо! Это дельный совет!
(73) не совсем понимаю о чем вы. Уточните пожалуйста.

http://www.itilium.ru/itilium/detail.php?ID=349

(77) Клево. Вот как все автоматизирую, внедрим итилиум.

(78) я был в первой десятке кто внедрял итилиум.... версия 1.0 была практически не рабочей, мне пришлось ломать их защиту, отвязывать ключи, взламывать защищеные модули и т.д. короче был геморой тот еще... сейчас они конечно далеко ушли вперед, но я с той поры развиваюсвой HelpDesk, хотя развитием не назовешь, так кусками внедряю :)

(79) Это здорово. Вот хелп деск нужен. Я вот думаю о трекере каком нибудь... Думаю что он могет помочь или наоборот ухудшить.

(52) А у Вас есть понимание, что то что Вы описали и то к чему Вы стремитесь (управление проектами, ITIL) - хорошо, но очень дорого. То есть качество результата возрастает, у Вас есть отчетность по всяким разным показателям, Вы можете объяснить куда и почему ушли деньги, но вот стоимость любых  работ возрастает, причем очень резко (если делать "все по правильному", то в разы)? И сроки кстати тоже.

(81) Мы уперлись в то, что без учета время разработки возрастает в десятки раз, а при работе с учетом заявок, ТЗ и проектов в разы. Так что выбор очевиден.