Ситуация такая. Проект готов на 40%, вложено много усилий. Пришел заказчик посмотреть как идет работа, как проект и т.д. Заказчик из тех людей, про которых говорят top-management, т.е. в IT ни бум-бум. Ему показали актуальные планы, дали раскладку по бюджету на следующий год. Он посмотрел на все это и охренел — говорит, вы мне дали таааакой бюджет, у вас работает 40 человек и вы делаете программу, которую раньше в такой-то конторе Вася Пупкин написал за три месяца на коленке за одну ЗП. (К слову проект — конструктор ERP систем.) Мы начинаем ему объяснять, что вот смотрите же методология такая используется, тестировщики работают и т.д. А он в ответ — какие нафиг тестировщики, если проект не готов, они ведь нужны на 2 недели перед сдачей системы — ну и в таком духе дальше. В общем мы от такого дела слегка офигели и решили встретиться чуть позже, чтобы к разговору подготовиться более детально.
Сейчас у меня есть одни сутки, чтобы найти подход к мышлению top-management и объяснить чем мы тут занимаемся. При этом я умом понимаю, что этот человек прав — он в IT не разбирается и у него есть пример, когда Вася Пупкин, который нефига не знает ни о безопасности, ни о корпоративных системах, написал программу, которая визуально выглядит точно также за 3 месяца — значит мы его где-то обманываем. Этот человек ведь не разбирается в том, что за внешне похожей визуальной мордочкой лежит тонна кода, которого у Васи Пупкина и в помине небыло. При этом top-management не понимает наших объяснений про процессы, про качество и т.д. и т.п. Вероятно к нему нужно найти подход на языке цифр.
Кто был в такой ситуации? Посоветуйте что делать? Буду благодарен, если кто-нибудь даст ссылки на какие-либо цифры или официальную статистику серьезных и авторитетных источников, в которых будет написано, что если......, то проект завалишь. Например, статистика неуспешных проектов, причины провала проектов и т.д. и т.п. Возможно у кого-то также есть сравнительная таблица стоимости владения системами, такими как SAP, Axapata и т.д. Может быть есть цифры стоимости разработки таких систем и т.д. В общем буду признателен за любую помощь, за любые цифры, которые могут мне помочь.
А>Ситуация такая. Проект готов на 40%, вложено много усилий. Пришел заказчик посмотреть как идет работа, как проект и А>т.д. Заказчик из тех людей, про которых говорят top-management, т.е. в IT ни бум-бум. Ему показали актуальные планы, А>дали раскладку по бюджету на следующий год. Он посмотрел на все это и охренел — говорит, вы мне дали таааакой бюджет, А>у вас работает 40 человек и вы делаете программу, которую раньше в такой-то конторе Вася Пупкин написал за три месяца А>на коленке за одну ЗП. (К слову проект — конструктор ERP систем.)
Требования есть? C кем согласованы? Какие еще существенные (подписываемые, либо прилагающиеся к договору) документы есть в проекте?
Планы с какой детализацией?
Этот человек — он кто? Какова его роль в проекте? Он подписывал договор, он владеет бюджетом, он будет подписывать акты? Кто на стороне заказчика заинтересован в проекте, кто находится в курсе дел?
Здравствуйте, Аноним, Вы писали:
А>Всем доброго времени суток.
А>Ситуация такая. Проект готов на 40%, вложено много усилий. Пришел заказчик посмотреть как идет работа, как проект и т.д. Заказчик из тех людей, про которых говорят top-management, т.е. в IT ни бум-бум. Ему показали актуальные планы, дали раскладку по бюджету на следующий год. Он посмотрел на все это и охренел — говорит, вы мне дали таааакой бюджет, у вас работает 40 человек и вы делаете программу, которую раньше в такой-то конторе Вася Пупкин написал за три месяца на коленке за одну ЗП. (К слову проект — конструктор ERP систем.) Мы начинаем ему объяснять, что вот смотрите же методология такая используется, тестировщики работают и т.д. А он в ответ — какие нафиг тестировщики, если проект не готов, они ведь нужны на 2 недели перед сдачей системы — ну и в таком духе дальше. В общем мы от такого дела слегка офигели и решили встретиться чуть позже, чтобы к разговору подготовиться более детально.
Требования к системе зафиксированы? С заказчиком согласованы?
На этот год объем трудозатрат, milestones согласованы? Проект идет в графике?
Есть у вашей команды опыт реализации подобных проектов? Просто в этом случае можно было бы аппелировать к опыту предыдущих проектов. А так позиция выглядит честно говоря слабоватой.
В эти 40% реализации хоть какой-то видимый бизнесу функционал входит? Если да, то наличие тестеров можно обосновать. Если используется что-то типа RUP, то можно разрисовать всех по ролям.
Странно конечно все это, похоже что просто урезается IT-бюджет на следующий год и идут всевозможные политические игры, поэтому аппеляция к разуму и цифрам мало поможет. Есть на стороне заказчика люди, которые заинтересованы в проекте и которые могут влиять на принятие решений по проекту?
Немного флейма все-же будет — а бизнесу точно нужен был конструктор ERP-систем? А не просто программа складского учета валенок?
Здравствуйте, <Аноним>, Вы писали:
А>Всем доброго времени суток.
А>Ситуация такая. Проект готов на 40%, вложено много усилий.
Шансов у вас мало. Вам нужен физически развитый пузатый дядька, добродушный душой и хорошо владеющий предметом финансы. Который бы мог полностью определить критические показатели, и убедить партера в неизбежности успеха вашего проекта и ваших людей. Что-либо конкретно вам советовать безсмысленно, т.к. не видя цифр -> нет расчетов...
Надо найти функциональные отличия вашего продукта от того, что сделал Вася Пупкин. Методология и процессы это НЕ отличия. Если отличий нет, то дело труба (и заказчик совершенно прав). Стоимость и скорость поддержки, расширяемость, поддерживаемая нагрузка, наличие документации это тоже отличия (правда, такому заказчику лучше на конкретных примерах)
И я бы предложил пересмотреть с ним план работ на следующий год и ввести этапы. Этап — набор важных бизнес функций. Согласовали – сделали. Пусть он (ну или пусть делегирует кому-то) контролирует, за что платит деньги чуть более детально, чем бюджет на год.
И я бы разобрался с Пупкиным. Если это было сказано просто чтобы надавить – надо вежливо отжимать, чтобы создать более реальное представление о затратах. А если и в правду нечто подобное было разработано за 3 человеко месяца, а не за 960 (40 чел, 2 года) то что-то у вас не так.
Re: Помогите не потерять заказчика
От:
Аноним
Дата:
05.09.07 09:38
Оценка:
Возможно, что уже поздно.
Несмотря на развитый у вас процесс, вы похоже упустили очень важный пункт.
Заказчик должен быть вовлечен в процесс разработки.
Если вы его видите раз в год, когда он подписывает бюджет на следующий год,
то его реакция довольно ожидаема.
Здравствуйте, Аноним, Вы писали:
А>Кто был в такой ситуации? Посоветуйте что делать? Буду благодарен, если кто-нибудь даст ссылки на какие-либо цифры или официальную статистику серьезных и авторитетных источников, в которых будет написано, что если......, то проект завалишь. Например, статистика неуспешных проектов, причины провала проектов и т.д. и т.п. Возможно у кого-то также есть сравнительная таблица стоимости владения системами, такими как SAP, Axapata и т.д. Может быть есть цифры стоимости разработки таких систем и т.д. В общем буду признателен за любую помощь, за любые цифры, которые могут мне помочь.
Делаешь раскладку по вашей системе — скока строк кода будет занимать ГУЙ, логика, и прочее. Показываешь, скока процентов от нее занимает ГУЙ — если он большой, то тоже делаешь по компонентам.
Берешь систему Васи Пупкина, которую он сделал за три месяца. Строишь из головы для нее раскладку — если она будет похожа по гую — выделяешь отдельной строкой этот гуй.
Показываешь две картинки из квадратиков — иллюстрируешь, что ГУЙ занимает небольшую долю от всей системы.
После этого — берешь требования к вашей системе — объем описания в страницах, общее количество поддерживаемых сценариев. Сравниваешь с предполагаемой системой Васи Пупкина. Показываешь, что ваш гуй сложнее, и обясняешь, почему строк кода планируется больше. Обосновываешь сроки, исходя из того, что один программер в среднем по индустрии колбасит 20-25К строк отлаженного кода в год (все включено — дизайн, требования, тестирование, кодирование, отладка — все). Показываешь калькуляцию, типа как в автосервисе — нормочасы там, то, се. Чтоб идиоту было понятно, почему получается так.
Считаешь, сколько надо времени просто пройтись по этим сценариям ручками, один раз. Это будут трудозатраты на один тестовый прогон. А делать его надо многократно — объесняешь что исправления ошибок тоже надо проверять. Чтобы не говорил, что тестирование — это две недели.
Показываешь, что тестер работает в конвейре — вы делаете систему по фрагментам, тестер тестирует блок, вы в это время приступаете к следующему. Типа, вы укладываете работу тестера в конвейр. Это, право слово, очень упрощенная картина, зато любому дураку понятно — что уже готово, то и тестируем.
GL>Надо найти функциональные отличия вашего продукта от того, что сделал Вася Пупкин.
Вообще это занятие почти бессмысленно, потому что никто не знает, что на самом деле делал Пупкин и
делал ли вообще. Сначала надо понять, кто такой этот товарищ, что от него зависит, почему он наезжает (откат не дали?),
что может предпринять. Может быть, он вообще не влияет на судьбу проекта.
Как показывает практика, аргументированный спор с ходячим телевизором редко бывает удачен; может тут нужны не аргументы, а классическая сауна с водкой и ммм... массажистками.
Hello, Gaperton!
You wrote on Wed, 05 Sep 2007 11:34:38 GMT:
G> Делаешь раскладку по вашей системе — скока строк кода будет занимать G> ГУЙ, логика, и прочее. Показываешь, скока процентов от нее занимает G> ГУЙ — если он большой, то тоже делаешь по компонентам.
Ставлю пирожок, что это не сработает Объясню почему — у людей, занимающий
высокие должности, время — самый ценный ресурс, поэтому информацию наверз
надо подавать кратко и понятно (как для прапорщиков ). Твой метод требует
большого кол-ва времени на объяснение.
На самом деле тут вина ПМ:
— слабая коммуникация с заказчиком
— не снижены риски по проекту из-за большого срока: можно было разбить на
итерации и сдавать кусками.
Вариантов улаживания ситуации 2:
— хороший
— плохой
По-хорошему надо ему вкратце показать план работ (с прогресом работ), где
будут распианы задачи и роли. Т.е. типа
1. задача1
1.1. Анализ (2 аналитика)
1.2 Девелопмент (табун кодеров)
1.3 Тестирование (девушка на выданье)
Лучше всего, чтобы этот план был утвержден и на нем стояла подпись
Главная идея в том, что работа тестировщиков — запланирована. Ткнуть пальцем
в линию "мы здесь".
Чтобы действовать по-плохому, нужно было перед стартом проекта собрать кучу
подписей. Тогда топ — ваш
ЗЫ По поводу Васи — тут мне понравилась аналогия с китайским автопромом
With best regards, Yury Kopyl. E-mail: hrg@yandex.ru
Posted via RSDN NNTP Server 2.1 beta
Re: Помогите не потерять заказчика
От:
Аноним
Дата:
06.09.07 19:57
Оценка:
тут советовать совершенно ничего нельзя, разве что попросить автора честно перед собой (не в форум) ответить на следующие вопросы:
1) может ли автор для себя честно сформулировать свою роль и ответственность в этом проекте ? ну и расписать, кто в проекте персонально отвечает за бабки, документы, код, программистов, здравый смысл с обеих сторон?
2) проект представляет собой ниверсальную систему учета всего с[c]ущего(или, что еще круче, ее конструктор ), или это просто набор формочек, которые поставят часть учета? Может, 1С/студенты рулят для этой задачи?
3) не путает ли автор проблемы финансирования и собственно разработки? имеет ли смысл мешать в одну кучу разные проблемы (деньги, огранизация разработки, коммуникации) ?
4) а может этот топ-менеджер просто [ч|...]удак ( и послать его к девкам или на ..., в зависимости от его реальной значимости ) ?
Здравствуйте, <Аноним>, Вы писали:
А>Всем доброго времени суток.
А>Ситуация такая. Проект готов на 40%, вложено много усилий.
"40%" совершенно ничего не говорит. Вы можете описать что сделано русским языком? Какой объем работ, необходимых заказчику уже реализован и внедрен?
А>(К слову проект — конструктор ERP систем.)
Вот на этом месте я бы сразу насторожился, если бы услышал подобное от разработчиков.
А>, которую раньше в такой-то конторе Вася Пупкин написал за три месяца на коленке за одну ЗП.
А что вы вообще должны в итоге сделать? Конструктор или ERP-систему?
По поводу вашего сообщения вспоминается вот такая история, прочитаная у anatolix'a
Для начала обращу ваше внимание, что за все это время работа над изначальной целью системы фактически не было начата, был макроязык, дизайнер форм, средство для работы с базой даных. Но не было даже базовых модулей изначально запланированной бухгалтерской системы. Мы как программисты искренне считали работу над средством разработки более важно чем над бухгалтерской системой. Более важной она было просто потому, что казалось нам более интересной. Вопросы бизнеса нас вообще мало волновали. Стандартный наш ответ на просьбу "а напишите вот такую форму" был "О это же клевая возможность, а давайте напишем движок с помощью которого мы будем реализовывать данную функциональность"
Здравствуйте, Andy Panda, Вы писали:
А>>(К слову проект — конструктор ERP систем.) AP>Вот на этом месте я бы сразу насторожился, если бы услышал подобное от разработчиков.
Это точно, если вместо решения конкретной задачи начинают делать конструктор или фреймворк — с большой вероятностью это может окончиться плачевно.
Здравствуйте, hrg, Вы писали:
hrg>Hello, Gaperton! hrg>You wrote on Wed, 05 Sep 2007 11:34:38 GMT:
G>> Делаешь раскладку по вашей системе — скока строк кода будет занимать G>> ГУЙ, логика, и прочее. Показываешь, скока процентов от нее занимает G>> ГУЙ — если он большой, то тоже делаешь по компонентам.
hrg>Ставлю пирожок, что это не сработает Объясню почему — у людей, занимающий hrg>высокие должности, время — самый ценный ресурс, поэтому информацию наверз hrg>надо подавать кратко и понятно (как для прапорщиков ). Твой метод требует hrg>большого кол-ва времени на объяснение.
Верно. При выборе метода я исходил из следующего:
1) Что нужно было делать при старте проекта — неважно, ситуация кризисная, надо выбирать оптимальное поведение "здесь и сейчас".
2) Для этого, надо вычислить мотивацию топа. Она, судя по рассказу, такая — он в шоке от объема работ и бюджета, он не понимает почему так и думает, что ему морочат голову — его знакомый Вася пупкин сделал "то же самое" за 3 месяца — и предъявленный ему бюджет противоречит здравому смыслу. Другими словами, топ не понимает, за что он платит такие большие деньги.
3) Бить надо в корень. Решение крайне простое — объяснить топу, простым и понятным образом, за что он платит деньги. Если вы не измените его убеждения, у вас ничего не выйдет.
4) Весь фокус в том, как объяснять. Необходимо задействовать по максимуму вещи, которые ему покажутся понятыми, наглядными, и очевидными, принеся в жертву точность изложения. Однако, объяснять надо все равно.
hrg>На самом деле тут вина ПМ: hrg> — слабая коммуникация с заказчиком hrg> — не снижены риски по проекту из-за большого срока: можно было разбить на hrg>итерации и сдавать кусками.
Чья тут вина — в данном случае совершенно не важно. Человеку срочно требовалась помощь, ответ на вопрос "что делать", а не "кто виноват".
hrg>Вариантов улаживания ситуации 2: hrg> — хороший hrg> — плохой
hrg>По-хорошему надо ему вкратце показать план работ (с прогресом работ), где hrg>будут распианы задачи и роли. Т.е. типа
hrg>1. задача1 hrg>1.1. Анализ (2 аналитика) hrg>1.2 Девелопмент (табун кодеров) hrg>1.3 Тестирование (девушка на выданье)
Не сработает. Топу до лампочки, чем вы занимаетесь — анализом девелопментом или тестированием — он ничего в этом не понимает и в короткой дискуссии у вас нет шансов объяснить ему детали процесса разработки. У него в контрпримере Вася Пупкин, которого он вам сразу приведет.
hrg>Лучше всего, чтобы этот план был утвержден и на нем стояла подпись
Уже поздно.
hrg>Главная идея в том, что работа тестировщиков — запланирована. Ткнуть пальцем hrg>в линию "мы здесь".
Это да, но опять бесполезно, потому что вы здесь, а Вася Пупкин уже давно "там", о чем вам сразу напомнят.
hrg>Чтобы действовать по-плохому, нужно было перед стартом проекта собрать кучу hrg>подписей. Тогда топ — ваш
Здравствуйте, Andy Panda, Вы писали:
А>>(К слову проект — конструктор ERP систем.) AP>Вот на этом месте я бы сразу насторожился, если бы услышал подобное от разработчиков.
А>>, которую раньше в такой-то конторе Вася Пупкин написал за три месяца на коленке за одну ЗП. AP>А что вы вообще должны в итоге сделать? Конструктор или ERP-систему?
Отличный вопрос. Честно? Я бы лично за такой проект на месте топа не платил. Предпочтя внедрение 1Сv8 или Axapta/Navision, которое я бы отаутсорсил сторонней компании.
Но автор просил флейма не поделу не разводить А>>Просьба не по делу флем не разводить.
Так что молчу
[Skip]
А> Он посмотрел на все это и охренел — говорит, вы мне дали таааакой бюджет, у вас работает 40 человек и вы делаете программу, которую раньше в такой-то конторе Вася Пупкин написал за три месяца на коленке за одну ЗП.
Почему тогда заказчик не у Васи программу покупает?
Объясню почему — у людей, занимающий 
