Про разработку информационных систем…
 

Сегодня как в кашмарном сне в очередной раз перечитываю "документы", ранее "подготовленные" для реализации IT проекта, с которым я работаю. Я вполне нормальный чайник в IT бизнесе, однако и мне страшно видеть, как можно "не уметь" работать и готовить документы. Невольно вспомнил топик в баш.орге, который сразу начал упорно искать и отыскал:Так вот и мой вопрос: кто знает статистику по проценту проваленных IT проектов в Узбекистане? В госсекторе? В частном секторе? Может кто-нибудь подетится своим опытом, то было бы интересно.

Оффтоп:

Цитата:

Сообщение от Nadir Zaitov (Сообщение 175858) кто знает статистику по проценту проваленных IT проектов в Узбекистане?

Здесь лучше будет озвучить количество разваленных (и не реализованных в итоге) проектов... :(

Хочется думать (базируясь на отсутствии у меня отрицательных данных по проектам на основе технологий HP), что таковых нет. Большинство проваленных проектов с компьютерной техникой не являются ИТ-проектами, так как предусматривали только оснащение рабочих мест (например, поставки в МНО и МВиССО).

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

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

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

Если это - игра слов, то возможен и второй вариант: до поставщика наконец дошло, что именно хотел заказчик! :)

Охотно
1. Все требования формируются в результате предварительного обследования и однозначно выражаются в техническом задании
2. Весь процесс внедрения проводится в четком соотвествии с согласованным и утвержденным техническим заданием, календарным планом
3. Любое изменение функционала или требований к АС только после проведения испытаний на соответствие действующему ТЗ и сдачи проекта в опытную эксплуатацию, на основании дополнительного соглашения и обязательно дополнительных денежек.

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

1) Вроде все хорошо. Компьютеры, операционная система, офис, антивирус на все компьютеры.... Стоп.. а где централизованное управление антивирусами и раздача сигнатур спросите вы? Нет. Не предусмотрено... ни софта, ни железа (сервера) - в другой пакет перенесли (кстати, раз тендеры разные - решения могут быть разные: например, локальный софт от Касперского, а центральный от NOD32 :)). А к интернету компьютеры подключать нельзя "по определению" :)

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

3) Выяснилось, что люди не представляют, ЧТО ТАКОЕ растаможка и какие документы и в каком количестве нужны... думаю что делать - за...думался до дыр в мыслях! Решил просто с Вами, ребята, пообщаться пока дыры сами залатаются (с подсознанием распараллелился :)).

Так..... скоро тендер намечается? ;)

Завидую Вам “белой завистью”. Реализовать проект по такой схеме – большое искусство как аналитиков, разработчиков и менеджеров проекта, так и проектной рабочей группы заказчика (особенно, если обошлось без допсоглашений и дополнительных денежных инъекций). Ни разу не только не участвовал, но и не видел (можно сказать, что плохо смотрел :)) проекта по разработке заказной информационной системы, где бы предокончательный вариант системы (сданной в опытную эксплуатацию) полностью совпадал бы с требованиями, четко и однозначно, определенными в утвержденном техническом задании, которое не претерпело никаких изменений со дня утверждения. Может быть за исключением проектов, где техническое задание (не в стандарте ГОСТ34 или ГОСТ19) подготавливала одна компания, а реализовывала другая компания.

IMHO, данный подход ошибочен и обречен на неуспех в проектах по разработке и внедрению информационных систем. Такой подход (называемый каскадным подходом или "водопадом") в современных реалиях приведет к огромному увеличению стоимости проекта и к увеличению сроков ввода в промышленную эксплуатацию. Кроме того, ни один вменяемый заказчик, если ему дороги его деньги и время, не пойдет на такие жесткие условия - после утверждения технического задания ничего нельзя изменить до ввода в опытную эксплуатацию; ну а потом можно, но только за дополнительную плату. Данный подход (с некоторыми оговорками) применим при внедрении готовых решений при наличии грамотных специалистов, как со стороны исполнителя, так и со стороны заказчика.

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

Даже несовершенный в современных реалиях стандарт ГОСТ34.602-809 (Техническое задание на создание АС) допускает изменения к ТЗ на стадии разработки и запрещает изменения на стадии приема-сдачи.

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

Так давайте вернемся к этапу формирования ТЗ, как к документу основопологающему в проекте.
Существуют входные качественные и количественные параметры, а именно:
1. Нормативная база (Законодательство, должностные инструкции и прочая прочая прочая) - это кстати может меняться в процессе формирования ТЗ и до его утверждения... скажем - в целях оптимизации... согласны?
2. Персонал и материально техническое обеспечение - тоже может менятся в процессе формирования ТЗ и до его утверждения... скажем в целях соотвествия техническим требованиям к предполагаемой системе.
3. Кваллификация персонала - точно будет менятся (кто в здравом уме покупает бибику если на ней некому ездить?)

Если на этом этапе все сделано и удовлетворяет требованиям Заказчика к проектируемой системе (то есть полностью отвечает его ожиданиям и удовлетворяет его потребностям) то о каком изменении может идти чем речь?

В том-то и дело, что когда имеется ТЗ и план-график, то это выгодно не только разработчику но и заказчику, т.к. он всегда знает с кого и что спросить. И проект в этом случае (в случае грамотного ТЗ) не будет не укладываться в сроки и не потребует никаких дополнительных затрат.

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

Всем привет!

Однажды я прочитал эту книгу....долго думал!


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

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

С другой стороны ТЗ составляется вместе с исполнителем, так что ошибки в ТЗ - проблема обоих сторон. Исполнитель виноват деже больше Заказчика, так как именно Исполнитель должен был всесторонее изучить потребности - это проблема в граждансом кодексе звучит как действие под аФфектом и в принципе Заказчик (если подумать и "правильно" посудиться) может объявить договор не действительным по причине именно такого "аффекта"... короче проект может развалиться от одного дурняка, возможно и незначительного и ваша категоричность ту не уместна.

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

Надир - Вы это... людей то не пугайте. Давайте на банальных, общепонятных примерах
1. ТЗ на ИТ инфраструктуру для СУБД.. в ТЗ порешили что сервак, к примеру, имеет большую, достаточную, дисковую подсистему (DAS)
Много памяти, много процессоров. 4 езернет контроллера, RAID офигенный, ОС Windows 2003 R2 Std, СУБД SQL 2005 Std. (ИОПсы, террафлопы - все подсчитали по какой нить формуле или взяли из сайзера производителя... не в этом дело). Зашибись? Подписали.
3. Процесс закупки и доставки прошел как нельзя лучше - железку отгрузили, расстаможили, собрали... тут и лицензии подошли (конвертик)
2. В процессе интеграции и миграции у заказчика появились\сформировались новые требования - нужен отказоустойчивый кластер.
Заказчик согласен пересмотреть условия ТЗ. Готов подписать допу без
увеличения стоимости - буквально слезно просит бамажку.
Ну и как Вы, интегратор, поступите? ;)

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

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

Я как закачик ;) буду не "слезно просить уложиться в бюджет", а требовать, так как Вы меня "пидманули" - дали неработоспособную небезотказную систему, сволочи акаянные! А ведь знали, что не заработает... а что за "бамажку" Заказчик "просит" - в смысле допу или доплицензии и почему вообще они в конвертике?

Не факт... это смотря что написано в ТЗ. Может быть такое (но работоспособное, как ни странно) Заказчику вообще не нужно :).

Не... со мной такой номер не пройдет - ТЗ то уже утверждено и подписано ;)
Допа - дополнительное соглашение
Лицензии по программе корпоративного лицензирования приходят в запечатанном конверте с указанием номера лицензиара и его реквизитами. Ключей нет :)

Просто никто не захотел судиться. Узбекистан на востоке, а восток дело тонкое. Я бы не церемонился и судился бы и выбивал все деньги обратно до последнего пенни обратно, в любом случае проект завалится. Нужно большее, чем утвержденное вами в том числе ТЗ. Тут проблемы не связаны с изготовлением, а с проектированием, а проектировали ВЫ. Пусть проектировалось со мной вместе, но я не специалист и им быть с учетом договора подряда не обязан, иначе зачем мне были б нужны ВЫ :) Суд аргументы скорее примет, а Вас назовет аферистом. Конечно все это только ИМХО, но жить может :).

Надир - Вы опасный человек, так что меня можете вычеркнуть из списка потенциальных водкопоглатителей.
Не проканает - потому как объектом договора на первом этапе служит утвержденное Вами ТЗ, на втором реализация проекта в строгом соответствии утвержденному ТЗ. Шаг влево шаг вправо - деньги на бочку.
Так все и будет гарантированно работать согласно утвержденному и согласованному ТЗ. А Ваши "ночные озарения" можете оставить на следующий проект с моим участием - все сделаем. :)
Суд может меня назвать кем угодно в неофициальной, дружеской беседе. Но рассматривать будет только подписанные документы (контрактные обязательства). Так что все Ваши самые сокровенные желания (в рамках проекта) за достойное вознаграждение могут быть выполнены кваллифицированной командой :) Только платите :)

Полностью с Вами согласен. Можно делать один проект всю жизнь и так и не закончить его.:)
Говоря о разработке заказной информационной системы в этот список необходимо добавить требования, по которым в будущем очень часто возникают споры между заказчиком и исполнителем: Детальные требования к функциям, выполняемым ИС; Требования к модели данных и атрибутам информационных объектов; Требования к стандартам пользовательского интерфейса и т.д.
Если на все время разработки “заморозить” техническим заданием вышеуказанные требования (а они являются неотъемлемой часть ТЗ), то в случае неточного изложения требований или их изменения в процессе разработки, заказчик получит систему, не удовлетворяющую его потребностям. Очень трудно заказчику, не являющемуся специалистом в разработке АС, при разработке ТЗ предусмотреть все точно и сразу, видя прототип системы только на бумаге в виде диаграмм, описаний и т.д. И это не повод разработчикам выкручивать руки заказчику и требовать дополнительных вознаграждений не вовремя процесса разработки, а после сдачи в опытную эксплуатацию.
Процесс реализации проекта по созданию АС не может четко уложится в рассматриваемую жесткую схему на 1, 2, 3 (и только на 3, получив основные деньги, выделенные на проект, мы готовы вернуться на шаг 1 за дополнительное вознаграждение). В процессе будет постоянно возникать необходимость возврата к предыдущим этапам и в уточнении и (или) пересмотре ранее принятых решений, если мы хотим, чтобы проект имел реальный успех.
Поэтому на этапе техно-рабочего проекта (разработки) применяется итеративный метод, когда заказчик может видеть прототип работающей системы, анализировать прототипы автоматизируемых функций на соответствии потребностям его бизнеса и при необходимости вносить изменения и дополнения в техническое задание по договоренности с исполнителем. Естественно, исполнитель в случае трудоемкости предложенных изменений или дополнений вправе потребовать дополнительные суммы.
Другими словами, согласование результатов выполненных работ с заказчиком должно производится не в конкретной точке – сдача в опытную эксплуатацию, а в течении всего техно-рабочего проекта (процесса разработки). Оставляя ему (а также и себе) возможность на исправление допущенных ошибок в описании требований к системе в утвержденном техническом задании. После сдачи в опытную эксплуатацию никакого разговора о внесении каких-либо изменений или дополнений уже быть не может.

Vsevolod Usmanov, Я Вас понимаю - но я уже не занимаюсь "заказными разработками". Не барское это дело - скобки расставлять :)

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

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

Eldar Fattakhov, бюджет проекта - дело очень не простое. /Вам легко сказать, чт о нужно столько-то. А как нам оценить это? Как объяснить начальству? Как объяснить, что были многочисленные недоработки в проекте еще до нас и что бюджет уже запущенного проекта нужно увеличить в Эн раз. Политика. Нас просто не поймут.

Это и прочее ранее перечисленное - реальные суперсложности. Как в техническом и технологическом, так и в финансовом плане (не говоря уже о предпосылках морально-этического характера). "Я Вас прекрасно понимаю".

Для нового проекта объяснить не так уж и трудно. Если на том конце "телефонного провода" хотят слышать (даже не слушать). :)

УПС.... Так... Бюджет проекта. Есть какая то пирамида потребностей Маслова. У основания размещаем потребности, чуть выше имеющуюся на ИТ ежегодный объем финансирования. Сверху увенчиваем треугольник который описываем как цель, которую мы можем получить исходя из потребностей и коррелируя этапы объемом финансирования.
Самое сложное - утвердить ежегодный бюджет.
В противном случае - проект разрастется до непомерных потребностей, денег и сроков. И все - кирдык всей работе. Но это мое ИМХО и ИМХО руководителей компаний ежегодно планирующих бюджет. Можете с этим ИМХО не соглашаться - делайте через суд.

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

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

Чем не ложится в задачу? Давай, давай разъясняй мне, конкурент злостный, скажи мне пару умных слов что бы изменил свое мнение...