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

То что вторые счастливы - можно понять, но почему первые правы, да еще абсолютно?

Неплохо бы прикрепить возможность комментирования прямо в статье

80 просмотров и ни одного критического замечания. 1 отзыв в стиле "ЙОУ". кто знает, что это может означать?

80 просмотров - это потому, что я на тебя вчера ссылку поставил )

а отзывов нет, т.к. неудобно отзываться

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

А выводы, почему не делается целеполагание, я у себя расписал.

Хотел сразу отметить некоторый момент. Часто используется понятие модель требований. Это понятие довольно часто встречается и в иностранной, и отечественно литературе. Так же прослеживается и в case-инструментарии.

В очень интересной книге по требованиям: Элизабет Халл, Кен Джексон, Джереми Дик. "Разработка и управление требованиями"
<< Некоторые употребляют термин «моделирование требований». Это термин является неверным по сути. Моделируется реализация системы, а не требования к ней. Моделирование поддерживает наиболее творческий процесс - разработку реализации системы, выработку конкретных системных решений. Моделирование помогает инженеру уточнять и детализировать реализацию системы путем разбиения ее на компоненты при движении вниз от одного уровня требовании к другому. Требования это полный «снимок» того, что именно требуется от системы на каждом уровне. При этом детализация «снимка» увеличивается при движении вниз от уровня к уровню.>>

На происхождение цели ИТ проекта можно предложить как минимум два взаимнодополняющих взгляда:
- системное происхождение цели проекта - разрабатываемая система рассматривается, как часть надсистемы, обеспечиващая выполнение функций надсистемы;
...
Первый случай более упорядочен и предполагает точное знание будущего окружения ИТ системы. Обычно первый подход годится для разработки систем управления оборудованием, серверного ПО, конверторов, программ индивидуального пользования. В этом случае на первый план выходит техническое окружение системы и непосредственные требования к функционированию (программные интерфейсы, форматы, требования к быстродействию, надежности и т.п.)
 

Не могу согласиться с примером. В данном случае речь идет не о системе и надсистеме, а об объекте управления и системе управления. Последняя должна удовлетворять принципу Эшби. это очевидно, но система управления не является надсистемой или суперсистемой (поскольку именно такой смысл скрывается под "над" в описании автора)

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

Не понятна логика выводов. Любой проект, а тем более инновационный (а ИТ проект как мне думается и относится к таковым, то есть венчурным связанным с риском), подразумевает вопросы организации, выбора средств и т.п.
Мне не ясно из статьи в чем разница системного происхождения цели и проблемного, и почему они противопоставляются?

если кроме создания ПО не планировалось больше ничего - это принципиальная ошибка создателей сайта

Это камень в известный мне огород? 

Для того, чтобы не нести бремя этого риска самостоятельно любой исполнитель, чем бы он не зарабатывал себе на жизнь, ДОЛЖЕН УМЕТЬ ФОРМАЛИЗОВЫВАТЬ И ФИКСИРОВАТЬ НА БУМАГЕ ЦЕЛИ, относящиеся к его обласи компетенции, ВЫБИВАТЬ ПОДПИСЬ ЗАКАЗЧИКА под этими целями и ПРИТЯГИВАТЬ ЗА ЯЗЫК в случае попытки нагрузить избыточной ответственностью за чужие просчеты.

Может легче государство поменять, а лучше Галактику

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

Мне кажется, что в начале статьи нужно более четко сказать (ибо это ощущается при прочтении статьи) что фаза проектирования - есть нечто иное как фаза целеполагания. Т.е. постановка задачи, возникновение проблемы, поиск их причины, выбор цели системы, цели проекта и т.п., определение требования, анализ требования, реализация требования в виде проектных воплощений - все это целеполагание! Конструирование системы - есть целереализация. Наконец рефлексия - оценка достижения целей, корректирование и переконструирование если необходимо. Очевидно, учитывая современный опыт разработки ПО и системы активно использующих ПО, жеского разделения нет - есть сплав, фьюжен называемым agile. Но этот подход совершенно естественен для новационных венчурных проектов, каковыми ИТ-проекты по сути и являются.
Т.е. надо сразу высказаться определенно и точно - целеполагание - это не фиксированный шаг проекта, - это тело проекта, его бог и дьявол...

В общем статья создает двойственное впечатление. Начало както не гармонизируется с концом. Начали с понятия цели, кончили концепцией.

Мне кажется, статья должна быть образцом целепостановки и целедостижения. Т.е. нужно поставить цели статьи - чтобы они были понятны и соответстовали СМАРТ, а также были показаны результаты - достигли ли мы цели или нет, в чем возникло противоречие в ходе рассуждения. Ведь необязательно результат должен быть положительным - негативный дает постановку проблемы и потребность понимания ее причин

Спасибо Сергею за статью. Почитал и обсуждение в блоге Дениса.

Хочу обратить внимание на то, что при обсуждении проблемы целеполагания смешиваются два разных явления. Одним и тем же словом называются (или имеются ввиду) разные вещи. С одной стороны, цель - это то, к чему я стремлюсь, моя потребность, желаемый результат моей деятельности. Я сам управляю своим собственным поведением. Достижение цели зависит не только от интеллектуальной продуманности, но и от внутренней готовности и концентрации внимания. Значительные усилия требуются на борьбу со всякими отвлекающими, мешающими факторами. Я занят делом, решаю важную проблему, но каждые пять минут ко мне кто-нибудь подходит с вопросом, просьбой, звонит телефон и т.д. В реальной жизни у человека есть множество целей (и все важные), между которыми нужно переключаться, все успевать, отбрасывать лишнее, выбирать нужное и правильное ...

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

Далее. Стремясь грамотно и эффективно организовать свою деятельность, человек может использовать разные полезные инструменты и методики. Можно, например, сформулировать цели на бумаге, по пунктам, повесить бумагу над рабочим столом. Это мой рабочий инструмент. Если кто-нибудь завтра повесит над моим столом другую бумагу, должен ли я выполнять то, что там будет написано?

При обсуждении темы смешиваются две вещи:

• эффективное решение проблемы
• успешное взаимодействие с людьми

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

Если человечество для регулирования целенаправленной деятельности много лет успешно применяет SMART  . То для регулирования отношений тоже очень давно применяются другие подходы. Культура, ритуалы, нормы, правила, законы и т.д. служат механизмами устранения и регулирования конфликтов между людьми. Стандарт - вот это слово. Часто не понимаем, зачем он нужен. Думаем, что стандарт помогает сделать качественный продукт. Ну в какой-то мере это и так. Впрочем изготовить действительно отличный и качественный продукт можно и без соблюдения стандартов. Выполнение процедур, соблюдение стандартов нужно именно для урегулирования взаимоотношений с заинтересованными сторонами. Разговор о стандартах, понятно, отдельная история. Отрасль развивается быстро. Стандарты не успевают стареть ...

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

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

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

Не всякий ИТ проект венчурный и инновационный. Если, например, система учета, выполненная на FoxPro переводится под MS SQL+Delphi при том, что все устраивает то, как работала предыдущая система - это ИТ проект с известной спецификацией требований, но цель его не создать новую организационную структуру, а расширить возможности имеющихся технических средств.

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

Согласен ссылок мало. Но тут могу сказать, что формат именно этого материала не позволяет излагать слишком отсушенным языком.

ссылки это не отсушенный язык а признак зрелости и приемственности

Вот ты мне скажи, куда ссылаться для подкрепления тезиса о необходимости SMART целей и оперделения, что есть SMART?

ну скажем http://www.tonich.ru/glossary/term/?id=37
http://www.hrm.ru/db/hrm/0A1C8BB8A0CA78E4C3256F8700534EF9/category.html
http://www.improvement.ru/bibliot/decision/decision04.shtm
Можно найти и более интересное.

Обзор литературы нужен, но до него надо еще дожить.

Обычно с него и начинается все. Я понимаю - это авторский материал, а не научная работа. Кончено, этим можно пренебречь.

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

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

Смотря для какого. Концепция - это письменно зафиксированные цели проекта. Как только она утверждена можно говорить о том, что целеполагание почти закончено. Почти - на случай изменения целей, но они меняются не всегда.

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

Не все так просто, но попробуем.

Я и не настаиваю просто предлагаю... Решать тебе все равно.

Насчет изложенного Концептуального документа в статье.

Читаю сейчас 3-издание Лармана. Конкретное на мой взгляд чтиво.

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

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

На первой итерации фазы Развития идет дальнейшее уточнение видения, требований и т.д.

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

Семинар - это хорошо. Как бы мне хотелось сейчас провести такой семинар. Но получается так, что один из ключевых участников расположен в Новосибирске, два других в Питере (при этом один из них даже не подозревает, что его назначили ключевым), а третий (Заказчик), хоть и в Москве, но добиться его аудиенции невероятно сложно, а от его подчинённых толку, как оказалось, мало.

Семинар - это хорошо. Как бы мне хотелось сейчас провести такой семинар. Но получается так, что один из ключевых участников расположен в Новосибирске, два других в Питере (при этом один из них даже не подозревает, что его назначили ключевым), а третий (Заказчик), хоть и в Москве, но добиться его аудиенции невероятно сложно, а от его подчинённых толку, как оказалось, мало.

Забавная, но как я понимаю жизненная ситуация. Странная, хотя бы по тому, что решение же делается для Заказчика, а он ишь вроде как неособо и заинтересован.
Хотя может данное исключение - подтверждение правила? Главное цена вопроса: если в такой позиции вы-таки работаете несмотря на трудности, значит все-таки это выгодно, либо деваться некуда. Но это уже смахивает на феодолизм.

Интересно - а как на Западе. У того же Лармана? Неужели у него самого никогда не было опыта беганья за Заказчиком и умоления его об встречи. Может и не было, тут уж кто перед кем круче...

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

Ну, как говорится, "зри в корень".

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

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

1. Западный заказчик на много более замотивирован на участии в проекте. Наши заказчики даже в ЮМЛ моделях разбирались

2. Ну а что нельзя провести веб/тел семинар? Было бы желание.

3. Ну давайте посмотрим картику РУПа или ОпенЮП, концепция/БМ прорабатывается в основном на первых этапах, естественно, когда требования уточняются может/должна уточняться концепция, но уже при разработке она не трогается.

4. Без условно, документы надо создавать ТОЛЬКО по необходимости. Маленький проект - концепция 2-3 листа (проблемы, ЗЛ, нужды, фичи). Средний/большой проект - концепция полее точно описывает границы (цели, проблемы, ЗЛ, нужды, фичи, БМ и т.д.)

5. Опять же здесь стоит разделить два разных продукта - создание с нуля и внедрение/кастомизирование. Как я понимаю Сергей описывает больше опыт во втором.

Сергей, что-то не загружается продолжение. Проверь ссылку, или это сервис упал?

Сергей, статья прикольная. Мысль понятная. Читается легко. Правда, как обычно много ошибок - может пропустить через word?

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

Сумбурный текст со скандальным названием "Из жизни проктологов"

Почему сумбурный? Чувствуется, что написано на одном дыхании, читается легко, и всё понятно.