Что написано пером…
«Что написано пером, того не вырубишь топором» гласит русская пословица. Прежде чем начинать любое внедрение программных продуктов, необходимо получить письменное описание целей и задач внедрения, подписанное руководителем. Но возникает вопрос: «Руководителем какого уровня/должности должен быть подписан такой перечень?».
В идеале перечень целей и задач внедрения должен быть подписан руководителем верхнего уровня (собственником, генеральным директором). Если предприятие достаточно крупное, то должен быть найден или появиться приказ, в котором четко указана фамилия, имя, отчество и должность человека, который отвечает на предприятии за ведение ИТ-проекта. И уже этот приказ обязательно подписывается руководителем верхнего уровня, уполномоченным подписывать приказы. Иными словами должно произойти формальное делегирование полномочий от одного лица другому. И копия этого приказа должна лечь в папку внедренца.
В формулировке приказа должны появиться слова «имеет право подписывать документы по ведению ИТ-проекта». И уже совсем хорошо, если руководитель проекта со стороны заказчика «имеет право подписывать договор по ведению ИТ-проекта». Тогда можно считать, что управление проектом нашло своего «хозяина».
В своей практике я стараюсь, чтобы такой приказ был оформлен на финансового директора предприятия. В самом деле, именно финдиру нужна и ясна самая главная цель любого внедрения: повышение прозрачности учета и снижение издержек предприятия. Все остальное — лишь детализация этой главной цели. Хотя именно детали часто меняют общую картину.
Чего мы добиваемся? Мы должны определить на предприятии лицо, сочетающее права и ответственность для дальнейшей работы. Причем это лицо должно обладать достаточным административным ресурсом.
Ошибки из практики:
- • Руководителем, ответственным за ИТ-проект, назначен начальник ИТ-отдела или единственный программист. В этом случае ответственный не обладает достаточным административным ресурсом. Исключением является должность ИТ-директора.
- • Приказ оформлен от фирмы «А», а внедренец числится или заключил договор с фирмой «Б».
- • Формулировка приказа расплывчатая, типа «имеет право вести ИТ-проекты».
- • Руководитель не имеет административного влияния на рядовых исполнителей, задействованных в процессе внедрения. Например, начальник производственной лаборатории подчиняется только директору по производству, а ответственным лицом назначен финдир.
- • Основные цели внедрения высказаны только устно. При попытке внедренца оформить их в письменном виде и получить подпись непосредственных заказчиков, получен отказ в подписи. Этот момент должен особенно насторожить внедренца.
Демо-версия
Старый анекдот: «Однажды святой Петр и дъявол боролись за душу человека. Святой Петр показал душе райские кущи, где пели святые. А дъявол показал душе кабак, где пили вино и обнимали девочек. Душа человека выбрала ад. Сразу исчез кабак, вино и девочки. Появились черти, огонь и сковородки. «А где же обещанное?» — спросила у дъявола изумленная душа. «Это была демо-версия!» — пояснил дъявол».
Крайне редко при встрече с руководителем вы сможете составить о нем полное и правильное представление. Большинство людей сначала изображают «демо-версию». Причем, как ни парадоксально, среди руководителей действительно крупных предприятий я встречала больше тех, чье впечатление, производимое от первой встречи, практически не отличалось от того, которое осталось после окончания работ. Именно общение с этими людьми и дало мне те знания, которые я сейчас использую на практике. Хотя далеко не всегда наши рабочие отношения были идеальными.
«Чтобы не разочаровываться — не надо очаровываться» — говорила моя мудрая бабушка.
«По делам их узнаете их» — это изречение из Библии я вспоминаю, когда при внедрении сталкиваюсь с очень красноречивыми и сладкоречивыми руководителями. При этом я совершенно не призываю заранее видеть в людях потенциальную угрозу. В принципе, впечатление, которое мы сами производим сначала, может сильно отличаться от того, которое сложится о нас после нескольких месяцев работы. Нужно учитывать еще и следующий момент: в бизнесе лучше выживают те, кто умеет производить хорошее впечатление.
А в чем смысл этого «лирического» отступления? Чтобы точнее и правильнее было наше представление о людях, с которыми мы работаем, чтобы понимать те риски, которые они могут нанести нашей деятельности, важно сосредотачиваться не на обещаниях, а на поступках.
«Мы с вами будем долго и плодотворно работать!» — это демо-версия. А вот подписанные документы или отказ от их подписания — реальный поступок. Отказ от подписания документов (целей и задач, макета документа и т.д.) — реальный риск получить потом отказ в том, что такие цели, задачи, документы и т.п. были когда-то предметом обсуждения и каких-то решений.
«Хороший человек — не профессия». (С) Ильф и Петров. В работе я предпочту иметь дело с человеком несимпатичным, но умеющим держать свое слово, профессионалом.
Ошибки из практики:
- • Устно озвученные цели через несколько месяцев меняются на иные. Руководитель, обаятельный в начале проекта, становится жестким тираном, угрожающим разными карами. Другой вариант: руководитель остается мягким, добрым, участливым, но ведет свою закулисную игру против вас.
- • Макет документа/отчета, не подписанный заказчиком, переделывается много раз.
- • Задачи, поставленные напрямую пользователями, минуя ответственного за ведение ИТ-проекта, не оплачиваются. Хотя устное согласие руководителя на их выполнение было получено.
Договор договору рознь…
После того, как вам ясны цели внедрения и вы поняли, что можете их реализовать хотя бы на 50%, наступает очередь подписания договора. Те, кто работает непосредственно на предприятии, могут заменить Договор на Устав проекта. Смысл и того и другого: определить основной набор документов, который будет оформляться и подписываться в течение ведения проекта и правила поведения сторон в основных случаях.
1. Предмет договора (устава). В данном параграфе лучше употребить слово «сопровождение», если трудно определить конечный объем работ. Если используется слово «внедрение», а конечный объем работ не известен, то я добавляю «по договору используется итерационная технология ведения проекта. Данная технология подразумевает совместную работу Заказчика и Исполнителя, в процессе которой вырабатываются требования к структуре и наполнению базы данных. Задание на внедрение согласовывается между Заказчиком и Исполнителем на очередной этап работ. В Задании определяется срок выполнения и результат работ». Так достижение большой цели разобьется на маленькие невзрачные задачи, без выполнения которых светлого будущего не достичь.
2. Обязанности исполнителя. Прежде всего, должно быть указано лицо, ответственное за ведение работ по договору со стороны Исполнителя. Оно может и не совпадать с руководителем, ответственным за ведение работ по ИТ-проекту.
Самая грандиозная ошибка на проекте — это поддаться эйфории от предвкушения колоссальных и приятных перспектив, которые сулит внедрение обеим сторонам. Даже на круизных лайнерах ведётся вахтенный журнал и ведётся он «для прокурора». Поэтому обязанностью исполнителя обязательно должно быть ведение ежедневного учета выполненных работ. Для себя, как внешнего исполнителя, я использую лист учета рабочего времени (ЛУРВ), макет которого приложен к статье. Но особенно подробно в ЛУРВе работу не опишешь. Поэтому еще веду рабочую тетрадь, в которой описываю текущие проблемы учета, возможные задачи на будущее и прочие «мелочи». К ведению такой же тетради приучаю ИТ-сотрудников заказчика. Важно не только описать выполненную работу, но и получить подпись сотрудника, с которым эта работа проводилась. Это может касаться и демонстрации типовых документов или отчетов, и выработки требований или обкатки новых объектов.
Разработку программного кода на территории заказчика обычно вести сложно. Поэтому в договоре мы указываем, что «работы, связанные с доработками купленных ПП или разработкой новых конфигураций по заданию Заказчика, осуществляются на территории и технике Исполнителя. Передача разработок может осуществляться Исполнителем путем пересылки данных по электронной почте на адрес Заказчика или в офисе Заказчика».
3. Обязанности заказчика. Теперь в договоре прописываем лицо, ответственное за руководство работ со стороны Заказчика. Это именно то ФИО, приказ на которого уже хранится в нашей папке внедренца. Именно этот человек будет подписывать Задание, ЛУРВ, Отчет и Акт выполненных работ.
Так как я являюсь внешним внедренцем, то указываю в договоре в обязанностях заказчика ежедневное копирование базы данных для исключения потери данных.
Если ИТ-сотрудник заказчика способен сам вести работы по объединению конфигурации с новыми разработками, то и эту функцию лучше описать в договоре.
4. Сдача-приемка работ. Проще всего планировать работы на один месяц вперед, что не исключает прогнозное планирование на более длительные сроки. Но на будущий месяц работы должны быть определены с точностью 90%: определены объекты для доработки с подписанным ТЗ (техническим заданием), даты посещения заказчика для обучения, отладки или приемки объектов программного продукта. Все это должно быть отражено в Задании, которое подписывается обеими сторонами.
В течение месяца время, отработанное исполнителем у заказчика, фиксируется в листах учета рабочего времени. Важно подписывать ЛУРВ сразу! В крайнем случае, на следующий день. То, что отложено на более длительные сроки, забывается. И совсем недопустимо откладывать подписание работ на конец месяца. Халтура при таком подходе неизбежна. По окончании месяца копии ЛУРВ прикладываются к пакету документов, который отдается на подпись заказчику. Оригиналы исполнителю лучше оставлять у себя.
В конце месяца составляется Отчет о выполненных работах, суммирующий краткие записи ЛУРВ и дополнительные разработки, проведенные на территории исполнителя. Конечно, указываются только те разработки, которые прошли проверку у заказчика.
В Акте выполненных работ производится расчет стоимости выполненных работ, как произведение итоговых часов по Отчету выполненных работ за месяц на стоимость 1 рабочего часа.
По окончании каждого календарного месяца обеими сторонами подписывается акт приемки-сдачи работ. В случае отказа со стороны заказчика подписания акта приемки-сдачи работ, заказчик обязан предоставить письменный мотивированный отказ с указанием претензий по выполненным работам.
Лучше указать пункт, ограничивающий срок предоставления отказа с претензиями или подписанный акт выполненных работ. Иначе такое подписание может быть отложено на неопределенно долгий срок. С нашей точки зрения достаточно трех-пяти рабочих дней.
5. Цена, порядок и сроки расчетов. Кроме указания стоимости часа работы, важно указать срок, в течение которого должна быть произведена оплата после выставления счета. С крупным и платежеспособным заказчиком такой срок может достигать одного месяца. Но если есть риски по платежеспособности клиента, то срок должен быть меньше.
В договоре лучше указать и те действия, на которые имеет право исполнитель, если заказчик не выполняет обязательств по подписанию акта и/или по оплате счета. Таким действием может быть приостановление работ по договору и его расторжение в случае длительной задержки.
Необходимо помнить, что в договоре отражаются те положения, которые не противоречат Гражданскому кодексу. В случае, если в договоре не указано какое-либо положение, то используется прямая норма ГК РФ для договора возмездного оказания услуг, глава 39.
Текст договора, который мы используем на проектах, находится в файле к статье.
Договор лучше подписывать на каждой странице. Это удержит некоторых горе-руководителей от соблазна заменить одну из страниц договора.
Ошибки из практики:
- • В конце месяца внедренец приносит Акт на выполненные работы без расшифровок и документов ежедневного учета. В этом случае заказчик имеет полное право сомневаться в правомерности объемов выполненных работ.
- • Игнорирование в ЛУРВ колонки «Замечания». Если замечаний нет, то слово «нет» должно быть вписано в колонку. В противном случае замечания могут появиться тогда, когда вы этого не ожидаете.
- • Отсутствие подписанного «Задания» может привести к оспариванию необходимости работ, выполненных за месяц. И такое может произойти спустя несколько месяцев…
- • Продолжение работ без письменного мотивированного отказа или подписаного акта также может привести к оспариванию всех последующих работ. Руководство может изменить свои цели, не поставив вас в известность. Подписание акта или мотивированный отказ — это обратный сигнал, позволяющий определить, совпадают ли ваши цели. Это далеко не только формальность. Без подписанного акта ваш шанс получить оплату за свой труд равен нулю.
- • Длительное продолжение работ без оплаты по выставленным счетам даже при наличии подписанных актов может привести к неприятной перспективе судебного разбирательства. Риск остаться без оплаты особенно велик в начале и в конце проекта. Исходя из арбитражной практики, если по договору заказчиком произведена хотя бы одна оплата, договор считается вошедшим в силу. Но много ли франчей или фрилансеров будет подавать в суд на заказчика? И хлопотно, и затратно, и удар по репутации. Вот поэтому мы закладываем в договор ограничения по срокам оплаты счета и возможным действиям в случае отсутствия оплаты. Ведь никто не обязывает вас приостановить работу, вы оговариваете лишь право на это. Для себя мы решили, что можем рисковать только одним месяцем бесплатной работы на заказчика.
Без вины виноватые…
Чтобы быть хорошим пешеходом, надо побывать «в шкуре» водителя автотранспорта. Чтобы быть нормальным исполнителем, хорошо бы знать некоторые методы руководства.
Во-первых, в руководители часто идут люди, которые способны принимать решения в условиях значительной неопределенности. Есть ли у них интуиция — иной вопрос. Но то, что руководство бизнесом сопряжено с высокими рисками — факт. Согласно статистике из сотни зарегистрированных предприятий 90 погибнут в первый год своей деятельности, еще 9 — в течение трех лет после регистрации. Поэтому руководители многие решения будут принимать, основываясь не только на фактах…
Во-вторых, руководители менее склонны руководствоваться чувствами, в том числе и «всеобщей справедливостью». Поэтому их решения будут непонятны исполнителям. Исполнители ждут «благодарности», а могут получить лишь «мотивацию». Самое интересное то, что «ничего личного, это просто бизнес» — правильный подход для ведения бизнеса.
Есть еще одна фраза, приписываемая легендарному гангстеру Аль Капоне: «Пистолетом и добрым словом можно добиться большего, чем одним добрым словом». Поэтому руководители используют в общении с подчиненными и внедренцами целый арсенал оружия: гневно насупленные брови, резкий громкий голос, любые обвинения, в том числе и беспочвенные. Мало руководителей в провинции использует положительную мотивацию. Сделать человека виноватым и заставить его оправдываться словом и делом — древняя тактика руководства, любимая даже женами и тещами. Оборотной стороной использования руководством этой тактики на предприятии — отсутствие работы с претензиями. При слове «претензия» сотрудники ищут свой «пистолет».
В-третьих, власть ослепляет даже сильных духом. Иной руководитель нуждается не в хорошо сделанной программной системе, а в ежедневном, ежечасном подтверждении своего могущества. Спорить с ним также бесполезно, как и надеяться на убедительность ваших доводов. Только беспрекословное повиновение и готовность принять наказание за ошибочно принятые им решения. «Наказание невиновных и награждение непричастных» — старая формула руководства.
Эти методы органичны в менее развитых типах общества (рабовладельческом, феодальном). Давно и психология, и социология поняли, что больших успехов добивается человек, ориентированный на достижение цели, а не на избегание неудач. Избегание — это сдерживание собственной активности во избежание вероятных неудач и опасностей. Может быть, поэтому процесс внедрения программных продуктов — работа для позитивно настроенных людей, которых я вижу среди своих коллег и посетителей Инфостарта.
Ну, а если вам повезет встретить на внедрении хороших руководителей, то к хорошему вы привыкните быстро.
Удачи вам!!!
Related Posts
Оценка и планирование проекта
Мысли о видах информационных систем…
Конфигурация "Выдача пропусков и учет рабочего времени"
Управление ИТ-проектами. Модуль 3: продвинутый курс по гибкому управлению проектами. Agile. Первый поток. Вебинары проходят с 11 сентября по 27 ноября 2024 г.
Загрузка/Выгрузка Excel для справочника "Графики работы сотрудников"
Онлайн-курсы по управлению ИТ-проектами от Марии Темчиной
Спасибо, за статью! Хоть и многие вещи вроде в голове были, но все равно полезно порой порядок навести и свести все в одно целое.
ну, вот, опять
не примите, пожалуйста, за придирку, но после тезиса
читать уже невозможно
**
поясню: если в офисе, куда вы попали, считают карандаши, у вас остается одна цель — по-скорее уйти из этого офиса
(2) tango,
Под «карандашами» понимаются всякие мелочи? Тогда цель «уйти из этого офиса» должна стоять перед массой провинциальных внедренцев. Вот и пытаемся с помощью ПП показать более крупные утечки денег. В одной фирме недавно обнаружили, что они т/км считают и для пробега с грузом, и для порожнего пробега ОДИНАКОВЫМИ, соответственно и ГСМ списывают. А экономят на ручках и карандашах…
(3)
ну да. вот, макаревич, например, прогнул таки
**
нач.транспортного цеха (завгар или кто там был у них) здороваться перестал?
хороший пример на самом деле
интересы участников просто не могут совпасть с декларируемой целью внедрения. ни у одного, включая владельцев
Завгар стал заискивать, а обиделись собственники. Но это совсем другая история. Попробую через пару недель закончить статью «Спасение «Титаника»».
P.S. Макаревич мне тоже нравится, но вот прогнуть этот мир получается не всегда.
Мне всегда нравится конкретика в «раскладывании по полочкам». Даже не вчитываясь дотошно в весь текст, получил удовлетворение от перечней типичных ошибок.
Другое дело, что высокий руководитель и на собственную подпись наплевать может. Плавали, знаем…
PS. <Чтобы быть нормальным исполнителем, хорошо бы знать некоторые методы руководства.> Еще и наоборот: чтобы быть нормальным руководителем, надо пройти школу подчинения.
(6) Арчибальд,
Из истории известно, что самыми жестокими надсмотрщиками были бывшие рабы. Эту ситуацию я не стала описывать.
(7) я немного не о том. Я про японскую метОду прогона будущего топ-менеджера через все служебные ступеньки.
Цель у абсолютного большинства — энное время посидеть спокойно на тёплом месте за хорошие деньги, безотносительно декларируемой ахинеи вроде прибыли компании, захвата рынка и прочих «побед». И хорошо, если ваша автоматизация им в этом не мешает, а то мгновенно ополчаются или тихо саботируют. Ну и потом, «мы привыкли в экселе и доверяем ему». А цель учёта — не нарваться на проблемы перед вышестоящими, в т.ч. не сесть за лажовую бух.отчётность. И всё. 1С вообще нужна в первую очередь для правильной отчётности — это то немногое, что слишком тяжко делать в экселе.
Солидарен с Танго.
спасибо, интересно.
Про ЛУРВ хорошо, но почему не использовать какие либо программные средства для ведения проектов с дублированием на бумаге.
Например, если обговорить 90% дел будущего месяца, и если так и бывает, то можно вести все в известной JIRA и только по концу месяца, или по порядку выполнения дел, закреплять подписями на конечном Акте выполненных работ.
но это так… ИМХО
Лично мне с бумажками возиться очень не хочется, а так, мы ведь в ИТ сфере, будем же пользоваться благами оными.
(9) Yashazz, в рамочку (можно без последней фразы)
ЛУВР даже в электронном виде — это одна из причин, по которой 1снег может убить франя
Спасибо, весьма увлекательная статья! Все разложено по полочкам и с конкретными примерами. Хоть и не приходилось сталкиваться с очень крупными заказчиками, возьму на вооружение несколько пунктов.
«Чтобы не разочаровываться — не надо очаровываться» — красиво сказано )
Хорошая статья )
спасибо, статья чрезвычайно полезная
отличная статья! вот бы кейсы по внедрениям тут на ИС были бы а то в закладки все не запихнешь ( однозначно плюс!
очень полезная и главное (для меня) вовремя написанная статья, спасибо… многое понятно…а вот по поводу экономии — это конечно факт, трудно что либо доказывать «высокому» начальству, ведь они чаще всего думают, что 1эсник сел за комп … раз, два и готово… ну в общем, вы меня понимаете 😉
Спасибо. Полезно. Особенно понравились формулировки и бабушкина расшифровка.
Спасибо, от провинциального внедренца! Это как раз то чего мне не хватало!..
Хорошая статья, правильные подходы, можно рекомендовать к применению.
Однако, чтобы не доводить дело на качелей вокруг договора, управляйте ожиданиями клиента на всех этапах.
Аппетит приходит во время еды — четко определяйте границы проекта.
PS Ничто так не укрепляет веру в человечество как вовремя полученный аванс.
Спасибо! Хоть мне и не нужно заключать договоров, но очень интересно почитать о взаимодействии с руководством ))
Спасибо за статью. С большим вниманием слежу за вашими публикациями. Новая статья стала катализатором мыслей об изменении порядка работы с заказчиками. Конфигурации по управлению выполнением заказами, выложенные на инфостарте, грешат демонстрацией технической части и обходят вопрос личной методологии работы с заказчиком. Часто смотришь конфу и не понятно, а зачем почему сделано именно так. Ваш материал помог взглянуть на работу с заказчиком обзорно, с высоты птичьего полета. И что важно, мы видимо близки по психотипам, у вас не ощущается внутренней потребности к сверхрегламентации. Что проявляется во многих статьях об управлении проектами. Но это скорее часть психики человека, чем по настоящему обязательное условие работы. В вашей статье описан разумный баланс регламентации и документирования. 🙂
больше всего понравилось — «Ошибки из практики»
(0)
• Макет документа/отчета, не подписанный заказчиком, переделывается много раз.
• Задачи, поставленные напрямую пользователями, минуя ответственного за ведение ИТ-проекта, не оплачиваются. Хотя устное согласие руководителя на их выполнение было получено.
как будто про меня 🙂 спасибо за статью! буду работать над ошибками
(0) У Ал. Белова (спасибо ему огромное!!!)
взял на вооружение такую постановку
«За свой счет мы исправляем ошибки.
Ошибкой считается такая работа программы,
при которой не выполняется первичное требование заказчика,
сформулированное в форме примера и исправление ее требует модификацию
структуры конфигурации и/или программного кода.
Если первичное требование заказчика, сформулированное в виде примера,
выполнено, но найдена ошибка на другом примере, доработка производится за счет заказчика.»
(0) Как можно изменить текст договора про итерационность этапов, если договор квалифицируется как оказание услуг?
(26) Rustig,
Как показывает практика, не всегда удается следовать букве договора:
1) Заказчик отказывается/уклоняется от предоставления контрольного примера
2) Заказчик предоставляет контрольный пример не полный или с ошибкой
3) Разработка полного и качественного контрольного примера требует затрат больше, чем его реализация
4) Заказчик просто не способен его предоставить
5) Нет стандартов определяющих содержание контрольного примера
И все же наличие договора, лучше чем его полное отсутствие. И чем больше проект, тем эффект заметнее 😉
(28) я полагаю так, как я услышал Ал.Белова, надо задачу разбить настолько, чтобы по каждой мелкой задаче получилось предоставить пример. Можно пример подобрать самим, описать его в ТЗ, а дальше подписать это ТЗ у Заказчика. с поправкой, что реализация другого примера означает дополнительные трудовые и временные затраты, а значит должно быть вынесено в другое ТЗ. в общем декомпозиция и еще раз декомпозиция.
(28) а вообще, мне сложно о всех нюансах договориться с первыми лицами. даже если они все нюансы подписали не глядя. то потом не глядя и спросят, почему не работает. и бесполезно будет пенять на договор, если я не готов судиться.
а про выражение Ал.Белова про определение «ошибки» — очень кстати меня выручает. приведу пример: фирма сейчас не использует типовой функционал «групп доступа по складам», но типовой механизм заложен в программу. я сделал настройку-доработку функционала «Учет ТЗР», функционал полностью учитывает проведение поступления товаров и реализации по складам. Через полгода принимается решение руководством использовать группы доступности по складам, и механизм учета ТЗР, основанный на складах, не срабатывает… кто виноват?
(30) Rustig,
«Кто виноват?» — вопрос вечный, как соревнование брони и снаряда. Защититься на 100% невозможно. Я старалась показать те «грабли, которые валяются прямо на дороге». И еще показать, что надо уметь отличать необоснованные «наезды».
В конкретном случае я пошла бы на 50% стоимость изменений, так как случай явно попадает под ответственность обеих сторон.
Не знаю…не знаю… через пол года??? Если в пределах гарантийного срока, то бесплатно.
Если срок вышел — за деньги заказчика. Если данная функциональность оговаривалась заказчиком, но не была протестированна им — можно 50 на 50. Если функциональность не оговаривалась, но предполагалась, скорее всего за деньги заказчика.
НО… на будущее, если во время доработки приходится жертвовать заложенной функциональностью — то лучше поставить в известность Заказчика заранее и пусть сам выбирает либо «быстро и дешевле» либо «дольше и дороже» 😉
PAVI, как и все ваши публикации читаю в удовольствие. Люблю пословицы и цитаты из мудрых книг. Ну, а если еще и в приложении к любимой работе — то им цены нет. Спасибо вам и поклон бабушке. Наверно у нее есть еще много изречений, достойных стать поговорками.
PAVI Тоже люблю читать ваши истории! Если кому-то некоторым — лишь бы погрубить, что другой раз хоть и понимаешь что правда, но тошно читать. А ваши статьи всегда читаю взахлёб)))))
Спасибо всем за внимание к теме, дополнения и положительные отзывы 😉
(32) согласен
Было занимательно, спасибо! 🙂
Спасибо!
Скажите , какие накладные расходы (временные в %) добавляются при полном следовании вашим советам? Мне кажется один лувр добавит около 5-10%, плюс разбор примеров и написание тз по каждой итерации — еще 5-10.
Моя практика такова, что при крупном внедрении всегда прописан «переводчик» от исполнителя — он всегда на связи и может приехать или проконсультировать сотрудников и дать обратную связь разработчику. Никогда не удается с первого раза полностью сделать готовый инструмент, НО — регулярно платит только довольный заказчик — значит все таки приходится после внедрения дорабатывать — в разумных пределах — свои внедрения.
В общем моя практика — довольный заказчик и учитывание доработок в первоначальной стоимости.
(40) kuril,
Уважаемый Кирилл! Подписание ЛУРВ в моей практике занимает минут пять за один рабочий день. И с большинством заказчиков он — чистая формальность. НО! Эта формальность пару раз спасала меня от неадекватных требований заказчика. А один раз спасла заказчика от неадекватного наезда налоговой инспекции. Так что мой вывод — лучше делать ЛУРВ. А Ваши выводы Вы делаете сами :))
Что касается подписания ТЗ по каждой итерации — это только звучит громоздко. В процессе проработки новых требований рисуются новые формы документов и отчетов, подбираются контрольные примеры. Вот эти формы и подписываются. А еще подписывается задание на будущий месяц. Это хорошо организует и синхронизирует мыслительный процесс и действия исполнителя и заказчика. Но, опять, мое предложение не является обязательным для любого читателя Инфостарта. Мы тут просто делимся опытом…
(39) Avatarus,
Уважаемый Сергей! Ваша просьба «перекинуть прикрепленный файлик» противоречит правилам Инфостарта, где все обмениваются своим трудом. Напишите статью о Вашем опыте работы около 10 000 знаков, и Вам сразу начислят 10 $m. А эти $m Вы сможете использовать для любых Ваших потребностей. Есть еще вариант купить $m у администрации сайта.
Слово «нет» впоследствии вполне может быть дополнено тем, чего, по мнению заказчика, не хватает в доработанном ПП («нет [имя_функционала]»). Так что в этой колонке более рационально ставить зачеркивание на все строки по высоте пункта.
Здравствуйте! Я не успел скачать файл за 24 часа 🙁 Можно как-то повторить?
(44) вроде 30 дней есть, чтобы скачать повторно. 24 часа действительна ссылка.
Так что еще жмите на «Скачать файл».
К сожалению нет, опять sm просит, хотя в письме да, написано, что 30 дней можно запросить повторно(
(46) напишите в саппорт — они отреагируют быстро — день-два может быть
(46) Пожалуйста, проинформируйте меня о решении или о сохранении проблемы. Мы обязательно договоримся!