Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 103
Отличная статья. Сейчас правлю договор для нашей студии и данная информация как нельзя к стати.
спасибо. В закладах. Хочется только уже увидеть про составление ТЗ. Примерная логика есть в голове, но лучше бы с примерами и ссылкамми и идеями умных людей
Вообще это называется Scrum.
Scrum — это другая штука. Там есть такие персонажи, как скрам-мастер, там 30-дневные спринты и т.п.
В этой же статье я описываю разделение на этапы, фиксирование отношений и принцип ценности результата этапа для заказчика.
Вот, кстати, диаграмма по Scrum:
В этой же статье я описываю разделение на этапы, фиксирование отношений и принцип ценности результата этапа для заказчика.
Вот, кстати, диаграмма по Scrum:
Вообще, Scrum, конечно же, ни при чем.
Ну вообще, Scrum - это методология ведения самого процесса. Независимо от того, как оформлены юридически отношения с заказчиком и какие этапы содержатся в договоре.
Зависимость условий договора по срокам может быть, но отнюдь не обязательна в связи с какой-то методологией.
Зависимость условий договора по срокам может быть, но отнюдь не обязательна в связи с какой-то методологией.
Недавно для себя (еще пока не утвердили такой подход) набросал "процесс создания сайта". Получилось следующее:
1.Определение концепции, предварительные встречи и т.п. - 0% от стоимости
2.Составление технического задания на дизайн и технического задания на программирование, утверждение тех.задания на дизайн и программирование, утверждение стоимости — 20% стоимости.
3.Составление блок-схемы дизайна > утверждение. 10% стоимости.
4.Составление дизайна по блок-схеме > утверждение. 20% стоимости.
5.Верстка макетов дизайна.10% стоимости.
6.Программирование > утверждение. 20% стоимости.
7.Наполнение сайта контентом > утверждение сайта 10% стоимости
8.Обучение управлению сайта — 10% стоимости.
9.Принятие сайта, акты выполненных работ — 0% стоимости
Как такой подход? Правильный ли?..
1.Определение концепции, предварительные встречи и т.п. - 0% от стоимости
2.Составление технического задания на дизайн и технического задания на программирование, утверждение тех.задания на дизайн и программирование, утверждение стоимости — 20% стоимости.
3.Составление блок-схемы дизайна > утверждение. 10% стоимости.
4.Составление дизайна по блок-схеме > утверждение. 20% стоимости.
5.Верстка макетов дизайна.10% стоимости.
6.Программирование > утверждение. 20% стоимости.
7.Наполнение сайта контентом > утверждение сайта 10% стоимости
8.Обучение управлению сайта — 10% стоимости.
9.Принятие сайта, акты выполненных работ — 0% стоимости
Как такой подход? Правильный ли?..
У меня немного другой подход. Стоимость разработки задания зависит от категории сложности проекта (если грубо определять).
Дальше бывают проекты, в которых надо больше программистского труда, а бывают такие, где дизайнеры должны больше поработать. Это определяется уже на основе ТЗ.
Поэтому соотношения процентные могут меняться, причем довольно серьезно.
В принципе, если у Вас получается эмпирически, т.е. по опыту типичного проекта, такая процентовка — то значит так оно и есть. Если же цифры взяты просто так, то советую отследить несколько проектов и понять реальное распределение трудозатрат.
Дальше бывают проекты, в которых надо больше программистского труда, а бывают такие, где дизайнеры должны больше поработать. Это определяется уже на основе ТЗ.
Поэтому соотношения процентные могут меняться, причем довольно серьезно.
В принципе, если у Вас получается эмпирически, т.е. по опыту типичного проекта, такая процентовка — то значит так оно и есть. Если же цифры взяты просто так, то советую отследить несколько проектов и понять реальное распределение трудозатрат.
Недостаок такого процесса в том, что заказчику придется делать 7 платежей, а на такое не многие согласны. Бюджет вообще такое не понимает, у него два варианта: а) аванс+остаток, б) оплата по факту. Семь раз платить вам никто не будет. Если проект мелкий — существенные потери времени на плетежи. Если большой и растянут по времени — оплата не отражает выполненную работу. Лучше сделать в три оплаты: 1) 20-30% — потдверждение серьезности заказчика; 2) после выполнения 50% работы еще 50-60%; 3) после подписания акта выполненных работ (сдачи сайта) 30-10%.
PS безусловно, цифры зависят от суммы договора. Если проект не превышает 10000$, то можно сделать все и в два платежа (50%+50%). Если проект до 50000$, можно сделать три платежа. Если проект еще больше по деньгам и по времени, тут можно вообще платить абон.плату, скажем по 20000$ в месяц.
PS безусловно, цифры зависят от суммы договора. Если проект не превышает 10000$, то можно сделать все и в два платежа (50%+50%). Если проект до 50000$, можно сделать три платежа. Если проект еще больше по деньгам и по времени, тут можно вообще платить абон.плату, скажем по 20000$ в месяц.
На всякий случай хочу предостеречь против типичной ошибки - не путайте платежи со стоимостью отдельных кусков работы! Они могут быть совершенно разные.
Например, платежей может быть два: 50% предоплата и 50% по финальным актам (хотя это и не самый удачный вариант). Этапов же может быть 5-7 и их стоимость может быть прописана отдельно, исходя из ваших оценок стоимости ресурсов на реализацию данного этапа.
Совсем корректный вариант - это когда вы "ни разу" не работаете на клиента за свои деньги - предоплата покрывает начало работ, как только несколько этапов, укладывающихся в эти деньги выполнены, к очередной вехе должна быть привязана следующая оплата, покрывающая несколько следующих кусков и т.п. Таким образом количество платежей и их величины могут быть подобраны так как нужно. Опять же, всегда есть возможность остановить работы, если не получена соответствующая оплата, а не кредитовать клиента из собственных средств, что вообще говоря - нонсенс, особенно в больших проектах.
Например, платежей может быть два: 50% предоплата и 50% по финальным актам (хотя это и не самый удачный вариант). Этапов же может быть 5-7 и их стоимость может быть прописана отдельно, исходя из ваших оценок стоимости ресурсов на реализацию данного этапа.
Совсем корректный вариант - это когда вы "ни разу" не работаете на клиента за свои деньги - предоплата покрывает начало работ, как только несколько этапов, укладывающихся в эти деньги выполнены, к очередной вехе должна быть привязана следующая оплата, покрывающая несколько следующих кусков и т.п. Таким образом количество платежей и их величины могут быть подобраны так как нужно. Опять же, всегда есть возможность остановить работы, если не получена соответствующая оплата, а не кредитовать клиента из собственных средств, что вообще говоря - нонсенс, особенно в больших проектах.
Вы правильно заметили, что стоимость договора и порядок оплаты это разные вещи. И хотя в контексте нашего обсуждения это не совсем актуально, но вы сделали правильный вывод, что не нужно работать за свои деньги. Работа идет только за деньги клиента. Кончилась предоплата — инициируем новый платеж. Если проект долгосрочный, то рассчитываем burn rate команды разработчиков (с учетом накладных расходов), прибавляем сюда нашу рентабельность включаем в договор эту сумму, как сумму ежемесячного платежа. Очень удобно, заказчик знает, что каждый месяц он платит определенную сумму. Раз в квартал подписываем промежуточный акт выполненных работ на основании которого производится доплата, либо, наоборот, фиксируется сумма задолженности перед заказчиком. Спрашивайте, если у вас есть еще вопросы.
Похоже мы не совсем правильно друг друга поняли. Мой комментарий был ответом на Ваше замечание (во всяком случае так, как я его понял) о том, что выделение в проекте нескольких этапов с определенной стоимостью приведет к такому же количеству оплат, что неверно. Здесь мы вроде во всем разобрались :)
Насчет burn rate идея понятна, но сам подход, на мой взгляд, имеет ограниченную применимость. В условиях, когда состав и загрузка команды не меняется на протяжении проекта (часто в консалтинге) - может быть. В проектах создания/внедрения IT решений у Вас вначале может работать 2-3 человека на проектировании, в середине 10-15 на реализации, в конце 3-4 на тестировании и документировании.. В этом случае подход с использованием burn rate дает очень грубое приближение и, на мой взгляд, теряет смысл - клиент будет то хронически переплачивать, то недоплачивать (пусть тогда лучше платит по факту, каждый раз пересчитывать не проще..). Если мы понимаем объем работ, куда правильнее строить схему оплат и букирования исходя из Cost Plan'а проекта. Если не понимаем, варианта два - T&M контракт (если повезет) или разделение проекта на кусочки - определение объема работ отдельно (в идеале на T&M), выполнение - отдельно на условиях, согласованных по результатам исследования.
В описанном Вами варианте также клиенту придется платить ежемесячно, против чего Вы же возражали выше.. Ничто не мешает получить одну предоплату в начале и пока ее не "закрыли" ежемесячными отчетами и актами по трудозатратам (если мы говорим о T&M контракте) или закрытием этапов (FP/FFP контракты), следующих платежей можно не делать, хотя это вопрос договоренностей - кому-то действительно может оказаться удобнее платить небольшую сумму ежемесячно.
Вопросов у меня к Вам нет, если возникнут - обязательно напишу :)
Насчет burn rate идея понятна, но сам подход, на мой взгляд, имеет ограниченную применимость. В условиях, когда состав и загрузка команды не меняется на протяжении проекта (часто в консалтинге) - может быть. В проектах создания/внедрения IT решений у Вас вначале может работать 2-3 человека на проектировании, в середине 10-15 на реализации, в конце 3-4 на тестировании и документировании.. В этом случае подход с использованием burn rate дает очень грубое приближение и, на мой взгляд, теряет смысл - клиент будет то хронически переплачивать, то недоплачивать (пусть тогда лучше платит по факту, каждый раз пересчитывать не проще..). Если мы понимаем объем работ, куда правильнее строить схему оплат и букирования исходя из Cost Plan'а проекта. Если не понимаем, варианта два - T&M контракт (если повезет) или разделение проекта на кусочки - определение объема работ отдельно (в идеале на T&M), выполнение - отдельно на условиях, согласованных по результатам исследования.
В описанном Вами варианте также клиенту придется платить ежемесячно, против чего Вы же возражали выше.. Ничто не мешает получить одну предоплату в начале и пока ее не "закрыли" ежемесячными отчетами и актами по трудозатратам (если мы говорим о T&M контракте) или закрытием этапов (FP/FFP контракты), следующих платежей можно не делать, хотя это вопрос договоренностей - кому-то действительно может оказаться удобнее платить небольшую сумму ежемесячно.
Вопросов у меня к Вам нет, если возникнут - обязательно напишу :)
Во многом с вами согласен :)
Но по поводу burn rate есть возражения. Безусловно, вы правы в специфичности, но она не столь ограниченная. На _длинных_ проектах (3-5 лет) это золотой парашют для разработчика. Команда практически не меняется на продолжении длительного периода времени; в договор заложена, как правило, не цена, а порядок ее определения (по сути формула). Переплаты/недоплаты возможны на начальном и заключительном этапах, но не хронически. К примеру, 3-4 начальных месяца возможна ситуация, о которой вы говорите. Она же возможна и на заключительных месяцах (но существенно, даже крайне, редко, т.к. почти вся работа выполнена и можно анализировать реальные данные). Теперь представьте, что из 36 месяцев работы только 6 месяцев с, как вы выразились, хронической переплатой/недоплатой. На мой взгляд, идеальная ситуация.
Но по поводу burn rate есть возражения. Безусловно, вы правы в специфичности, но она не столь ограниченная. На _длинных_ проектах (3-5 лет) это золотой парашют для разработчика. Команда практически не меняется на продолжении длительного периода времени; в договор заложена, как правило, не цена, а порядок ее определения (по сути формула). Переплаты/недоплаты возможны на начальном и заключительном этапах, но не хронически. К примеру, 3-4 начальных месяца возможна ситуация, о которой вы говорите. Она же возможна и на заключительных месяцах (но существенно, даже крайне, редко, т.к. почти вся работа выполнена и можно анализировать реальные данные). Теперь представьте, что из 36 месяцев работы только 6 месяцев с, как вы выразились, хронической переплатой/недоплатой. На мой взгляд, идеальная ситуация.
Что ж, возражения принимаются :) Сам в таких проектах не учавствовал, но вполне могу себе представить ситуацию, когда это будет работать. Скорее всего речь идет о выделенной команде, которая садится надолго на какую-то оффшорно-аутсорсинговую работу? В этом случае мы просто говорим о разновидности T&M контракта, где для удобства клиент платит некую "абонентскую" плату за услуги по разработке/поддержке. В этих условиях вполне разумно.
ну прикиньте если стоимость проекта 3000 евро и на допустим 20 рабочих дней или 40 рабочих дней?
Думаете как вашим так и их бугалтерии будет в каф перерабатывать стоитько счётов? а у вас их 7 штук.
Думаете как вашим так и их бугалтерии будет в каф перерабатывать стоитько счётов? а у вас их 7 штук.
Более-менее верно, но лучше иметь более реальные (и более крупные) этапы, которые можно будет реально внести в договор и использовать. Мало кому будет приятно 7 раз платить по 10-20%. Ну и неточности есть (на мой взгляд). Например: 10% за обучение управлению — очень хочется подискутировать :). Цифры ведь должны быть обоснованы, иначе они становятся предметом для обоснованного торга.
Сколько времени у вас уходит на разработку сайта (минимум-максимум) или, например, вот этого http://studiomade.ru/portfolio/continent_site/?
Почему спрашиваю: ведь для того, чтобы каждый этап закрывать актами, нужно либо сроки раздувать, либо на это не обращать особого внимания. А работать и надеяться, что все будет закрыто документами, и оплата будет в срок. Потому как на оформление документов уходит по меньшей мере несколько дней — то «нет директора», чтобы подписать, то «менеджер с печатью поехал на таможню» и т.п.
Почему спрашиваю: ведь для того, чтобы каждый этап закрывать актами, нужно либо сроки раздувать, либо на это не обращать особого внимания. А работать и надеяться, что все будет закрыто документами, и оплата будет в срок. Потому как на оформление документов уходит по меньшей мере несколько дней — то «нет директора», чтобы подписать, то «менеджер с печатью поехал на таможню» и т.п.
О, этот сайт давно сделан, я тогда еще в другой компании работал. Обычно порядка 40 рабочих дней на сайт.
Чтобы закрывать каждый этап актами вовсе не обязательно так уж раздувать сроки. Многие этапы вообще параллельно могут идти, например, оформление и программирование.
Мы прописываем время, которое отводится на рассмотрение и подписание. Соответственно, пока это время идет, мы работаем по следующему этапу. К половине этого срока мы начинаем звонить заказчику и интересоваться, когда будут подписи-печати и т.п.
Чтобы закрывать каждый этап актами вовсе не обязательно так уж раздувать сроки. Многие этапы вообще параллельно могут идти, например, оформление и программирование.
Мы прописываем время, которое отводится на рассмотрение и подписание. Соответственно, пока это время идет, мы работаем по следующему этапу. К половине этого срока мы начинаем звонить заказчику и интересоваться, когда будут подписи-печати и т.п.
Не совсем согласен с тем фактом, что 3 раза по 2000 тысячи платить психологически проще, нежели сразу 6000. Заказчики сразу считают деньги и сложить 3 раза по 2000 проблем не составит. Поэтому, данный пункт, мне кажется, не совсем уместен. Это же бизнес, а не размен машинками в песочнице.
В остальном - хорошая схема.
Но давайте представим такую ситуацию - подрядчик подготовил дизайн, ждет деньги. Работа по вёрстке/программированию не движется. А у заказчика именно в этот момент срывается поступление финансовых средств на его банковский счёт и платить вам нечем. Но он добропорядочный и обязательно заплатит. Позже. Но вы-то не знаете, что он добропорядочный. Поэтому ждете оплаты. Соответственно, сдвигаются сроки сдачи проекта. Что делать в такой ситуации?
В остальном - хорошая схема.
Но давайте представим такую ситуацию - подрядчик подготовил дизайн, ждет деньги. Работа по вёрстке/программированию не движется. А у заказчика именно в этот момент срывается поступление финансовых средств на его банковский счёт и платить вам нечем. Но он добропорядочный и обязательно заплатит. Позже. Но вы-то не знаете, что он добропорядочный. Поэтому ждете оплаты. Соответственно, сдвигаются сроки сдачи проекта. Что делать в такой ситуации?
мне кажется, что изначально отношения должны быть построены на доверии, ограниченном пунктами договора. в таком случае может было бы уместно составить дополнение к договору, в котором описать процедуру при возникновении форс-мажорных обстоятельств в финансировании?
Просто боюсь, что вся эта нервотрепка с поэтапной оплатой, просрочками и т.д. ну никак не может способствовать налаживанию доверительных отношений. У нас же в России всегда так было - все самые сложные вопросы решаются за рюмочкой водки в ресторане/баре/кафе/кабаке/сауне и т.д. А договор - это так. Что бы было. Поэтому, нужно уметь лавировать между отношениями с заказчиком и пунктами своего же договора. Это правильно. В нашей стране по-другому нельзя.
наверное к вам юристы не приходили от каких-нить немаленьких клиентов и не говорили про договор, который вы с ними подписали ;)
А мы лавируем, иногда, в ущерб себе. Даем дополнительно срок на оплату, зато вот когда срок сдачи подходит, то заказчик "забывает" о том, что сам затягивал рассмотрение макетов и проч. И вот тогда мы показываем договор и говорим, что рассмотрение макетов свыше X дней, согласно договору, сдвигает сроки.
Так-то оно так, да не так :-) Пока что работает прием "всего за 99 долларов, 99 центов". И заплатить 2000 евро, но уместиться в остаток квартального бюджета, проще, чем ждать 6000 евро из следующего квартала.
Работа по верстке и программированию, как правило, движется, пока мы не видим явного злоупотребления нашим доверием.
Срывается поступление? Окей, предупредите нас, как только это стало известно и назовите срок оплаты. Мы пойдем навстречу, а заодно будем знать, рассчитывать ли на эти деньги или изыскивать где-то еще.
Если же совсем долго тянет — окей, пусть он берет кредит в банке на оплату по счетам. Не мы же в долги должны залезать, правда? Или, если совсем все плохо, приостанавливаем работу по взаимному согласию, передаем результаты, получаем какую-то оплату и гарантийное письмо на продолжение работ тогда-то и тогда-то. И работаем по другому проекту, а не висим в неведении, сжигая свои запасы.
Работа по верстке и программированию, как правило, движется, пока мы не видим явного злоупотребления нашим доверием.
Срывается поступление? Окей, предупредите нас, как только это стало известно и назовите срок оплаты. Мы пойдем навстречу, а заодно будем знать, рассчитывать ли на эти деньги или изыскивать где-то еще.
Если же совсем долго тянет — окей, пусть он берет кредит в банке на оплату по счетам. Не мы же в долги должны залезать, правда? Или, если совсем все плохо, приостанавливаем работу по взаимному согласию, передаем результаты, получаем какую-то оплату и гарантийное письмо на продолжение работ тогда-то и тогда-то. И работаем по другому проекту, а не висим в неведении, сжигая свои запасы.
Знаете, заказчик может и добропорядочный, но это не повод давать ему кредит. У нас есть 2 типа заказчиков (оба типа - добропорядочные). Одни - платят вовремя,, а другие - постоянно задерживают оплату, первые - динамично растут, вторые - или не растут, или потихоньку стагнируют. Так что еще важно правильно выбирать заказчика.
Всегда лучше иметь возможность требовать, в соответствии с грамотно составленным договором, и не пользоваться ей, потому что заказчик уж очень любимый, чем наоборот :) Проверено.
Что делать? Ждать оплаты. В конечном счете, оперируя сухими фактами это проблема исключительно заказчика.
В жизни, конечно, все сложнее и бывают нюансы: степень доверия, срок отношений, платили ли вовремя ранее, загруженность людей (т.е. ситуация "либо делаем неоплаченное либо балду пинаем") и т.п.
В жизни, конечно, все сложнее и бывают нюансы: степень доверия, срок отношений, платили ли вовремя ранее, загруженность людей (т.е. ситуация "либо делаем неоплаченное либо балду пинаем") и т.п.
Мы сначала заключаем договор на ТЗ, где определяется цена разработки. Потом уже заключаем договор, оплата по которому проходит поэтапно, но также иногда берем 50% предоплату, если проект небольшой.
По авторскому праву, советую всем предлагать полные неисключительные права, это позволит потом иметь исключительные права на дизайн или софт именно сутудии, многие конторы не обращают на это внимание. А исключительные права можно потом использовать очень эффективно и претензий не будет. Вот.
По авторскому праву, советую всем предлагать полные неисключительные права, это позволит потом иметь исключительные права на дизайн или софт именно сутудии, многие конторы не обращают на это внимание. А исключительные права можно потом использовать очень эффективно и претензий не будет. Вот.
На софт надо заключать лицензионное соглашение, на дизайн обычно клиенты просят исключительные права.
у нас удается впарить и неисключительные) Софт пишем на заказ поэтому там тоже договор, не лицензионное, обычно все исключительные тоже у нас.
Исключительные права дают возможность держать работы в портфолио?
Это всегда надо прописывать в договоре. Так, на всякий случай. А за "убрать из портфолио" или "снять логотип студии" просить увеличение стоимости сайта минимум в 1,5 раза, как мы и делаем.
Право ставить логотип и назваться автором — это неимущественное авторское право, оно неотчуждаемо, никто не может его у вас отнять.
Право ставить логотип и назваться автором — это неимущественное авторское право, оно неотчуждаемо, никто не может его у вас отнять.
Используете какой ни будь софт для тракинга проектов и задач?
Самое удобное как для студии, так по большому счету и для заказчика работать на условиях регулярной повременной оплаты (скажем 1 раз в месяц). Оговорюсь, что при этом разработка должна вестись по чему-то вроде Скрума или другой agile методики и применимо это к достаточно крупным проектам.
Как-то это всё до конца не продумано и неорганизованно. Куда легче, понятней и прозрачней для заказчика разработку делить на 2 этапа - "проектирование" и "реализация".
В проектирование укладывать структуру, прототипы, ТЗ, дизайн (не все шаблоны, а только концепцию - главную страницу и любую внутреннюю, например). А в реализацию - отрисовку шаблонов, вёрстку, программинг, контент.
При этом второй этап оценивать только по завершению первого. Ведь, например, только после ТЗ становится чётко и понятно - нужен заказчику простой корпоративный сайт или нужно фигачить какой-нибудь "искусственный интеллект". И только после придумывания дизайн-концепции становится ясно, понадобится ли покупать фотографии в фотобанках, проводить фото- или видеосъёмку, заказывать иллюстрации и т.д.
В проектирование укладывать структуру, прототипы, ТЗ, дизайн (не все шаблоны, а только концепцию - главную страницу и любую внутреннюю, например). А в реализацию - отрисовку шаблонов, вёрстку, программинг, контент.
При этом второй этап оценивать только по завершению первого. Ведь, например, только после ТЗ становится чётко и понятно - нужен заказчику простой корпоративный сайт или нужно фигачить какой-нибудь "искусственный интеллект". И только после придумывания дизайн-концепции становится ясно, понадобится ли покупать фотографии в фотобанках, проводить фото- или видеосъёмку, заказывать иллюстрации и т.д.
Но вообще, уважаемый Алексей, направление мыслей верное :)
проблема в том, что в более-менее сложных проектах по ходу реализации самое детальное ТЗ приходится корректировать в силу разных обстоятельств.
Если студия встает в позу и отказывается это делать - это невыгодно заказчику, в результате заказчик получает проект, который соответствует ТЗ, но реально отличается от того, что ему нужно, что приводит к трениям при сдаче и неудовлетворенности заказчика.
Если студия соглашается корректировать ТЗ, при жестком ТЗ такие корректировки требуют массу времени на процедурные вопросы и приводят к затягиванию достижения какого-то этапа и соответственно получению денег и недофинансированию.
Если студия встает в позу и отказывается это делать - это невыгодно заказчику, в результате заказчик получает проект, который соответствует ТЗ, но реально отличается от того, что ему нужно, что приводит к трениям при сдаче и неудовлетворенности заказчика.
Если студия соглашается корректировать ТЗ, при жестком ТЗ такие корректировки требуют массу времени на процедурные вопросы и приводят к затягиванию достижения какого-то этапа и соответственно получению денег и недофинансированию.
Всё упирается в максимально подробное и чётко написанное ТЗ.
Ну а в крайних случаях - доработки, выявленные после утверждения ТЗ, - за доп. деньги по доп.соглашению.
Ну а в крайних случаях - доработки, выявленные после утверждения ТЗ, - за доп. деньги по доп.соглашению.
угу, это в теории так
на практике это работает только для маленьких проектов
Если проект расчитан на полгода - 100%, что ТЗ придется обновлять. Если обновлять его и делать изменения после окончания работ по оригинальному ТЗ - страдает заказчик, если вносить правки по ходу работ - разработчик или оба.
на практике это работает только для маленьких проектов
Если проект расчитан на полгода - 100%, что ТЗ придется обновлять. Если обновлять его и делать изменения после окончания работ по оригинальному ТЗ - страдает заказчик, если вносить правки по ходу работ - разработчик или оба.
В крупных проектах написать четкое, подробное, окончательное ТЗ — задача практически нереальная (в разумные сроки и время).
Алексей, спасибо за разъяснения, но, проведя с клиентом максимально подробную работу и выставив аналитику (техписателю) чёткую задачу, написать окончательное ТЗ вполне реально.
Людмила, если вы не сталкивались с проектами в которых в ходе их выполнения возникала необходимость редактировать самое распрекрасное ТЗ, это не значит, что таких проектов не существует в природе.
Они существуют. Допоплнения к ТЗ это вариант выхода из такой ситуации, но у него есть ряд минусов, которые я уже упоминал:
- отнимается время на процедурные вопросы. Стоит ли подписывать дополнение к ТЗ если заказчик попросил, например, поменять фамилию главного бухгалтера на сайте (ну поменяли они его во время работы над проектом)? Очевидным ответом будет проще поменять без доп. соглашений, чем разводить писанину из-за 3-х минутной работы. Однако когда подобных 3-х минутных правок накапливается несколько десятков и еще пяток-другой правок на полчаса-час уже хочется сделать доп. соглашение и выставить за них счет. Как уже говорилось можно отправить, конечно, заказчика "в лес" со всеми этими правками до завершения цикла разработки, но в результате он будет не вполне доволен, а если правка более критична для бизнеса, например у интернет-магазина поменялся мерчант аккаунт, получается, что он и вовсе не сможет пользоваться разработанным сайтом
- зачастую приводят к сдвигу одного из основных уже оговоренных этапов, что негативно сказывается на финансировании проекта. Скажем у заказчика после утверждения половины макетов дизайна неожиданно сменился корпоративный стиль (скажете - бред, так не бывает, но в жизни бывает и не такое). Что делать? Работать дальше, по старому ТЗ - работа дизайнера в болшой степени идет в мусорную корзину. Принимать доп.соглашение - да, но в результате переработки уже сделанного сдвигается срок приема дизайна и оплата по нему. Студия "попадает" на проблемы с финансированием
Они существуют. Допоплнения к ТЗ это вариант выхода из такой ситуации, но у него есть ряд минусов, которые я уже упоминал:
- отнимается время на процедурные вопросы. Стоит ли подписывать дополнение к ТЗ если заказчик попросил, например, поменять фамилию главного бухгалтера на сайте (ну поменяли они его во время работы над проектом)? Очевидным ответом будет проще поменять без доп. соглашений, чем разводить писанину из-за 3-х минутной работы. Однако когда подобных 3-х минутных правок накапливается несколько десятков и еще пяток-другой правок на полчаса-час уже хочется сделать доп. соглашение и выставить за них счет. Как уже говорилось можно отправить, конечно, заказчика "в лес" со всеми этими правками до завершения цикла разработки, но в результате он будет не вполне доволен, а если правка более критична для бизнеса, например у интернет-магазина поменялся мерчант аккаунт, получается, что он и вовсе не сможет пользоваться разработанным сайтом
- зачастую приводят к сдвигу одного из основных уже оговоренных этапов, что негативно сказывается на финансировании проекта. Скажем у заказчика после утверждения половины макетов дизайна неожиданно сменился корпоративный стиль (скажете - бред, так не бывает, но в жизни бывает и не такое). Что делать? Работать дальше, по старому ТЗ - работа дизайнера в болшой степени идет в мусорную корзину. Принимать доп.соглашение - да, но в результате переработки уже сделанного сдвигается срок приема дизайна и оплата по нему. Студия "попадает" на проблемы с финансированием
Александр,
меня, безусловно, очень радует ваша способность угадывать, с чем я сталкивалась, а с чем нет, но вы не правы.
ТЗ не должно предполагать правок и дополнений. Если таковые возникают, то это делается за доп. деньги. Это всё, что было написано выше.
По поводу двух ваших ситуаций:
- в бюджет изначально закладывается некий буфер.
Это позволяет не забыть о таком понятии, как "клиентоориентированность". То есть выполнять все желаемые правки по мановению пальца заказчика, но за его счёт.
Если буфер исчерпывается - дополнительные деньги.
- если у заказчика в разгаре разработке случается аврал вроде смены фирменного стиля, например;
Тут вопрос крайне странен, потому что перерисовывать половину макетов, извините, забесплатно никто не будет. Ну я и компания, где я работаю, в частности.
Если таковое случается - тормозим работы, оцениваем стоимость дополнительной отрисовки, оплачивают, дорисовываем.
Где тут студия "попадает" на проблемы с финансированием, учитывая оплату за дополнительную работу, мне не совсем ясно. Разве что с отсрочкой финального платежа (по сайту, по дизайну, не важно) - так уж лучше она и доп.деньги, чем бесплатная работа.
меня, безусловно, очень радует ваша способность угадывать, с чем я сталкивалась, а с чем нет, но вы не правы.
ТЗ не должно предполагать правок и дополнений. Если таковые возникают, то это делается за доп. деньги. Это всё, что было написано выше.
По поводу двух ваших ситуаций:
- в бюджет изначально закладывается некий буфер.
Это позволяет не забыть о таком понятии, как "клиентоориентированность". То есть выполнять все желаемые правки по мановению пальца заказчика, но за его счёт.
Если буфер исчерпывается - дополнительные деньги.
- если у заказчика в разгаре разработке случается аврал вроде смены фирменного стиля, например;
Тут вопрос крайне странен, потому что перерисовывать половину макетов, извините, забесплатно никто не будет. Ну я и компания, где я работаю, в частности.
Если таковое случается - тормозим работы, оцениваем стоимость дополнительной отрисовки, оплачивают, дорисовываем.
Где тут студия "попадает" на проблемы с финансированием, учитывая оплату за дополнительную работу, мне не совсем ясно. Разве что с отсрочкой финального платежа (по сайту, по дизайну, не важно) - так уж лучше она и доп.деньги, чем бесплатная работа.
Людмила, по поводу моих догадок - вы сами написали "на практике абсолютно также" .
Буфер - вещь хорошая, однако когда он исчерпывается заказчик начинает удивлятся, а чего это раньше вы за это деньги не брали, а сейчас начали. Кроме того возникают опять процедурные вопросы: когда этот буфер исчерпался писать доп. соглашение на каждый чих, собирать чихи оптом или что-то еще делать
Во втором случае да, возникает отсрочка платежа по дизайну, на который вы рассчитывали. Это конечно лучше, чем работать бесплатно, но тоже не очень радует.
Мы сами в большинстве случаев сейчас работаем по описаной вами схеме "ТЗ-дополнения", и я все больше и больше убеждаюсь в ее плохой применимости к крупным и сложным проектам.
Чем больше проект - тем хуже она работает.
Буфер - вещь хорошая, однако когда он исчерпывается заказчик начинает удивлятся, а чего это раньше вы за это деньги не брали, а сейчас начали. Кроме того возникают опять процедурные вопросы: когда этот буфер исчерпался писать доп. соглашение на каждый чих, собирать чихи оптом или что-то еще делать
Во втором случае да, возникает отсрочка платежа по дизайну, на который вы рассчитывали. Это конечно лучше, чем работать бесплатно, но тоже не очень радует.
Мы сами в большинстве случаев сейчас работаем по описаной вами схеме "ТЗ-дополнения", и я все больше и больше убеждаюсь в ее плохой применимости к крупным и сложным проектам.
Чем больше проект - тем хуже она работает.
Ну да, на практике абсолютно также. То есть:
Тут где-то написано, что ТЗ не меняется никогда и ни при каких условиях?
см. также http://habrahabr.ru/blog/studiobusiness/…
Мы скатились от общего (изменений в ТЗ) к частному - их причинам.
По поводу буфера:
за пару "чихов" до конца предупреждение "извините, но вы исчерпали лимит доработок, ещё парочку внесем, так уж и быть, а всё остальное за дополнительные деньги".
Всё упирается в максимально подробное и чётко написанное ТЗ.
Ну а в крайних случаях - доработки, выявленные после утверждения ТЗ, - за доп. деньги по доп.соглашению.
Тут где-то написано, что ТЗ не меняется никогда и ни при каких условиях?
см. также http://habrahabr.ru/blog/studiobusiness/…
Мы скатились от общего (изменений в ТЗ) к частному - их причинам.
По поводу буфера:
за пару "чихов" до конца предупреждение "извините, но вы исчерпали лимит доработок, ещё парочку внесем, так уж и быть, а всё остальное за дополнительные деньги".
Это в идеальном случае. В реальном же часто оказывается, что у заказчика меняется видение какой-то части проекта, например.
Ну правда, поспрашивайте в больших софтверных компаниях, как оно бывает. Есть даже методологии, не вовсе не предусматривающие большого и окончательного ТЗ.
Ну правда, поспрашивайте в больших софтверных компаниях, как оно бывает. Есть даже методологии, не вовсе не предусматривающие большого и окончательного ТЗ.
Повторюсь еще раз: речь о крупных проектах.
Алексей, заказчик заказывает какую-то работу, скажем, построить дом. Если в процессе строительства он захочет балкон - ок, без проблем в рамках доп. соглашения.
Изменения в процессе работы бывают в двух случаях:
1. у заказчика изменились приоритеты;
2. мы не до конца продумали и недобинили систему.
Со вторым можно бороться и нужно делать это успешно. Пути решения первого я тут уже несколько раз писала.
Поэтому я не очень понимаю, каков смысл последнего комментария :)
Изменения в процессе работы бывают в двух случаях:
1. у заказчика изменились приоритеты;
2. мы не до конца продумали и недобинили систему.
Со вторым можно бороться и нужно делать это успешно. Пути решения первого я тут уже несколько раз писала.
Поэтому я не очень понимаю, каков смысл последнего комментария :)
А если он захочет кардинально поменять не построенную еще часть (половину)? Сначала достроите, потом разрушите? Не очень клиентоориентировано.
Зачем достраивать, простите?
За доп. плату переделаем уже достроенное, либо построим заново.
За доп. плату переделаем уже достроенное, либо построим заново.
ТЗ ведь придется дополнить.
Собственно, уже отвечала: http://habrahabr.ru/blog/studiobusiness/…
Это пункт №1.
Это пункт №1.
Ну дак как быть с изменением приоритетов-то? Большая часть диалога с вашей стороны лично мной была понята как "мы не реагируем на изменение требований в процессе работы над длинным проектом". Если я понял не верно — давайте просто сойдемся что я был невнимателен либо вы не очень точны и закончим бессмысленный диалог. Похоже все-таки наши точки зрения больше схожи чем различны.
Может быть мы говорим вот о чем. Факт номер 1: любое изменение ТЗ в процессе работы над ним вносит зачастую непреодолимый разлад в работу над проектом. Факт номер 2: большие проекты на практике подразумевают изменяющиеся требования, предугадать так это или нет практически нереально. Вывод: нет смысла описывать ТЗ на весь проект, имеет смысл писать ТЗ на конкретные участки работ, при этом, не допуская никаких изменений в ТЗ поскольку нормальный ход работ более ценен чем незначительная сумма "переработки" за которую заплатит заказчик.
Если мы оба об этом, то вы не были поняты сразу, но теперь взаимопонимание налаживается :)
Может быть мы говорим вот о чем. Факт номер 1: любое изменение ТЗ в процессе работы над ним вносит зачастую непреодолимый разлад в работу над проектом. Факт номер 2: большие проекты на практике подразумевают изменяющиеся требования, предугадать так это или нет практически нереально. Вывод: нет смысла описывать ТЗ на весь проект, имеет смысл писать ТЗ на конкретные участки работ, при этом, не допуская никаких изменений в ТЗ поскольку нормальный ход работ более ценен чем незначительная сумма "переработки" за которую заплатит заказчик.
Если мы оба об этом, то вы не были поняты сразу, но теперь взаимопонимание налаживается :)
RUP, например
В том-то и дело, что реализация сама по себе может быть достаточно длинной, трудоемкой и дорогой. См. пример с интернет-магазином и постепенно подключаемым к нему функционалом.
Подключаемый функционал - по доп. соглашениям, в чём проблема?
Изначально проектируем интернет-магазин с "каталогом-корзиной", потом обговариваем с заказчиком дополнительные модули, оплаивает, делаем.
Изначально проектируем интернет-магазин с "каталогом-корзиной", потом обговариваем с заказчиком дополнительные модули, оплаивает, делаем.
Ну т.е. вы, готовя ТЗ, сразу оговариваете, что ТЗ сделано не на весь проект, а только на его часть. Краткосрочную и не подлежащую изменениям. Именно об этом вам и говорят: на весь проект сразу ТЗ не сделать. Факт. А как уж быть конкретно, называть это "I, II очереди" либо "еженедельные сборки" — вопрос конкретного проекта и удобства\навыков работы команды в рамках конкретных методологий.
Вы путаете понятия.
1. есть понятие крупной системы, по которой у заказчика сформировались пожелания. Её можно спроектировать впоследствии с минимальными корректировками ТЗ.
2. понятие постоянно развивающегося проекта. Здесь увидеть конечную цель нереально, да и не нужно. И, естественно, конечное ТЗ написать невозможно.
1. есть понятие крупной системы, по которой у заказчика сформировались пожелания. Её можно спроектировать впоследствии с минимальными корректировками ТЗ.
2. понятие постоянно развивающегося проекта. Здесь увидеть конечную цель нереально, да и не нужно. И, естественно, конечное ТЗ написать невозможно.
Разговор идет о том, что пункт 1 на практике очень часто оказывается пунктом 2. Если ваш опыт в крупных проектах показывает что это не так, значит вы на удивление везучий человек.
Интересно, как вы с таким подходом справляетесь с ситуациями, подобными этой: цена проекта $100 тыс. Сделана половина. От второй половины заказчик хочет отказаться (модуль оцененный в половину проекта потерял актуальность, т.к. нашли готовый инструмент для этих целей). Задача ставится так: написать (небольшой по объему работ) модуль интеграции нового (стороннего инструмента) с разрабатываемой (готовой, по сути) системой. Осмелюсь предположить, что ничего приятного в ответ на предложение сначала завершить разработку в рамках ТЗ вы от заказчика не получите.
Интересно, как вы с таким подходом справляетесь с ситуациями, подобными этой: цена проекта $100 тыс. Сделана половина. От второй половины заказчик хочет отказаться (модуль оцененный в половину проекта потерял актуальность, т.к. нашли готовый инструмент для этих целей). Задача ставится так: написать (небольшой по объему работ) модуль интеграции нового (стороннего инструмента) с разрабатываемой (готовой, по сути) системой. Осмелюсь предположить, что ничего приятного в ответ на предложение сначала завершить разработку в рамках ТЗ вы от заказчика не получите.
Осмелюсь предположить, что ничего приятного в ответ на предложение сначала завершить разработку в рамках ТЗ вы от заказчика не получите.
А зачем предлагать завершить разработку в рамках ТЗ?
http://habrahabr.ru/blog/studiobusiness/…
А еще есть такая психолого-организационная проблема. Часто клиент не хочет оплачивать проектирование, мол это ваша работа и ее результаты тоже вам нужны, зачем мне проект? и второе: гендиру нужен точный бюджет. проще назвать с 30% запасом, чем убеждать что еще не все мол обсуждено
Это становится понятно до ТЗ, а после ТЗ становится понятно, что именно, как именно, когда и на каких условиях будет сделано.
Как будете решать ситуацию "дизайн не утвержден с пятой попытки"? :)
Прописывать в договоре.
"за эти деньги мы предоставляем 3 варианта дизайна. если ни один не подходит, работа считается выполненной, деньги не возвращаются".
"за эти деньги мы предоставляем 3 варианта дизайна. если ни один не подходит, работа считается выполненной, деньги не возвращаются".
Какая работа? "Реализация"? Т.е. и программирование и верстка и все-все-все считается выполненной?
Если да, то почти 100% пункт про "деньги не возвращаются" противоречит действующему законодательству.
Если да, то почти 100% пункт про "деньги не возвращаются" противоречит действующему законодательству.
Простите, вы о чём вообще? О какой вёрстке и программировании?
Я выше писала, что работу над проектом легче делить на "проектирование" и "реализацию", почитайте.
Дизайн относится к проектированию. При заключении договора на первый этап мы должны выдать следующее: ТЗ (структуру, прототипы) и дизайн.
Если мы написали ТЗ, а дизайн с третьего раза не принят, то первый этап считается выполненным.
Я выше писала, что работу над проектом легче делить на "проектирование" и "реализацию", почитайте.
Дизайн относится к проектированию. При заключении договора на первый этап мы должны выдать следующее: ТЗ (структуру, прототипы) и дизайн.
Если мы написали ТЗ, а дизайн с третьего раза не принят, то первый этап считается выполненным.
Было неочевидно, что дизайн входит в проектирование. В моем понимание это далеко не всегда так, поскольку в дизайне могут встречаться достаточно трудоемкие вещи, непосредственно к проектированию отношения не имеющие.
Не дизайн всех принципиальных страниц/технических шаблонов, а только концепция - главная + одна внутренняя.
Согласна, что называть "проектированием" отрисовку дизайна несколько странно, но в противном случае адекватного названия этому этапу не подберешь.
Согласна, что называть "проектированием" отрисовку дизайна несколько странно, но в противном случае адекватного названия этому этапу не подберешь.
Более того, неочевидно, что и ТЗ входит в проектирование :) Это только у разработчиков малых и средних сайтов так, в разработке ПО и ИС (и больших сайтов, которыми они являются) — это отдельные этапы/фазы.
К пункту о ТЗ.
Встречал в своей практике следующее. ТЗ готовит сам заказчик - то, как он видит сайт, причем очень подробно. А исполнитель готовит эскизный проект. Эскизный проект это нечто похожее на ТЗ. Точнее, это и есть ТЗ. Только глазами исполнителя. Вот как раз на создание эскизного проекта и можно заключать отдельный договор.
Сам не практикую такое. Но видится мне, что могло бы пригодиться.
Встречал в своей практике следующее. ТЗ готовит сам заказчик - то, как он видит сайт, причем очень подробно. А исполнитель готовит эскизный проект. Эскизный проект это нечто похожее на ТЗ. Точнее, это и есть ТЗ. Только глазами исполнителя. Вот как раз на создание эскизного проекта и можно заключать отдельный договор.
Сам не практикую такое. Но видится мне, что могло бы пригодиться.
Первые 1-2 встречи. Обсуждения внутри студии. Составление ТЗ по проекту. Составление Договоров. Составление ТЗ дизайнеру.
Это ведь всё время. Это всё деньги. Я считаю что первые 20%-30% надо бы брать сразу, хотя бы 100евро.
Может он передумать, заказ могут перебить конкуренты, ну всякое может быть. Вы простатите время, и вам ведь никто не заплатит!!!
Это ведь всё время. Это всё деньги. Я считаю что первые 20%-30% надо бы брать сразу, хотя бы 100евро.
Может он передумать, заказ могут перебить конкуренты, ну всякое может быть. Вы простатите время, и вам ведь никто не заплатит!!!
Прекрасный материал. Поддерживаю на 100%. Нельзя откусить и проглотить сразу килограмм колбасы.
У меня вопрос: как вы фиксируете факт передачи материалов? отправки макетов?
У нас часто бывает так: пока все хорошо, мы общаемся по электронной почте и телефонам, а если все становится критично или угрожающе, то отправляем заказные письма с описью и уведомлением, или отвозим официальное письмо на бланке с просьбой поставить печать, подпись секретаря и входящий номер. Это исключительно геморройная затея, город у нас 120 км длиной и сателлит Волжский рядом, но других юридически безупречных путей я не знаю.
Отвезти письмо — самый лучший способ. У меня не било ни одного прецедента чтобы не приняли.
У меня вопрос: как вы фиксируете факт передачи материалов? отправки макетов?
У нас часто бывает так: пока все хорошо, мы общаемся по электронной почте и телефонам, а если все становится критично или угрожающе, то отправляем заказные письма с описью и уведомлением, или отвозим официальное письмо на бланке с просьбой поставить печать, подпись секретаря и входящий номер. Это исключительно геморройная затея, город у нас 120 км длиной и сателлит Волжский рядом, но других юридически безупречных путей я не знаю.
Отвезти письмо — самый лучший способ. У меня не било ни одного прецедента чтобы не приняли.
У нас в договоре прописан порядок передачи материалов и подтверждения их приемки. Например, если передаем запрос какой-то или отчет, затребованный письменно, то просим подписать копию, поставить входящий номер.
Мы, кстати, поступаем немного по-другому.
У нас нет договоров. Есть аналогичный документ, который используют компании, бизнес которых ориентирован не на продукт, а на сервис (например, провайдеры). Это SLA, Соглашение об уровне сервиса.
Так вот, смысл в том, что этот документ НЕ имеет финальной суммы или сроков. Финальную сумму, сроки, объем работ и список имеют только короткие приложения к SLA, добавляемые со временем и по времени необходимости. Кстати, важно, что приложения именно "короткие" - лучше сделать "мало" и утвердить работу. Затем - следующий этап. В таком случае риски - минимальные для всех.
Акт подписывается по завершению работ по очередному приложению к SLA. Этот процесс может быть хоть бесконечен!
Т.е. сам SLA (в отличие от договоров, которые обычно приходится видеть) - содержит больше специфики и, в том числе, точный регламент НЕ того КАКИЕ работы проводятся, а КАК проводятся работы и на КАКИХ условиях.
Думаю, всем знакома ситуация, когда разработка давно закончена, но не сделана другая часть работ, "блокирующая" подписание акта и выплату. Вывод - надо делить этапы, разделять их на разные приложения к Соглашению SLA. И получается, что можно вести сколько угодно разных (даже очень мелких) работ или даже нескольких проектов параллельно. По одному SLA, в котором оговорены все условия.
Как кто-то уже упоминал выше в топике - может возникнуть проблема с тем, что "бухгалтерия не хочет" обрабатывать наборы актов. Здесь уже делать вывод в каждом конкретном случае.
Во-первых, можно комбинировать в одном акте работу по нескольким приложениям, а во-вторых, каждый решает для себя, что ему дороже - угодить клиенту или защитить себя.
И есть еще маленький аспект - здесь надо быть настойчивее и решать эти вопросы ТОЛЬКО с людьми, которые принимают решения. Бухгалтерия их не принимает - она только исполняет.
У нас нет договоров. Есть аналогичный документ, который используют компании, бизнес которых ориентирован не на продукт, а на сервис (например, провайдеры). Это SLA, Соглашение об уровне сервиса.
Так вот, смысл в том, что этот документ НЕ имеет финальной суммы или сроков. Финальную сумму, сроки, объем работ и список имеют только короткие приложения к SLA, добавляемые со временем и по времени необходимости. Кстати, важно, что приложения именно "короткие" - лучше сделать "мало" и утвердить работу. Затем - следующий этап. В таком случае риски - минимальные для всех.
Акт подписывается по завершению работ по очередному приложению к SLA. Этот процесс может быть хоть бесконечен!
Т.е. сам SLA (в отличие от договоров, которые обычно приходится видеть) - содержит больше специфики и, в том числе, точный регламент НЕ того КАКИЕ работы проводятся, а КАК проводятся работы и на КАКИХ условиях.
Думаю, всем знакома ситуация, когда разработка давно закончена, но не сделана другая часть работ, "блокирующая" подписание акта и выплату. Вывод - надо делить этапы, разделять их на разные приложения к Соглашению SLA. И получается, что можно вести сколько угодно разных (даже очень мелких) работ или даже нескольких проектов параллельно. По одному SLA, в котором оговорены все условия.
Как кто-то уже упоминал выше в топике - может возникнуть проблема с тем, что "бухгалтерия не хочет" обрабатывать наборы актов. Здесь уже делать вывод в каждом конкретном случае.
Во-первых, можно комбинировать в одном акте работу по нескольким приложениям, а во-вторых, каждый решает для себя, что ему дороже - угодить клиенту или защитить себя.
И есть еще маленький аспект - здесь надо быть настойчивее и решать эти вопросы ТОЛЬКО с людьми, которые принимают решения. Бухгалтерия их не принимает - она только исполняет.
P.S. Мы называем документ "SLA", так как это действительно документ, ориентированный на описание ПРОЦЕССА, а не ПРОДУКТА. Так как продукт - это что-то законченное, финальное, а процесс - это как раз то, что происходит и за что мы хотим получать свои денежки, даже если этот процесс не заканчивается.
Терминология необязательна, можно называть это Договором, если кому-то так удобнее, но это будет не очень верно концептуально, так как договор - это обычно набор некоторых конечных условий и все привыкли воспринимать его именно так.
Более того, часто SLA не исключает договор - бывает, что "чисто юридическая специфика" остается в договоре. И предметом договора является сам SLA, содержащий, в свою очередь, всю "специфику процесса".
Терминология необязательна, можно называть это Договором, если кому-то так удобнее, но это будет не очень верно концептуально, так как договор - это обычно набор некоторых конечных условий и все привыкли воспринимать его именно так.
Более того, часто SLA не исключает договор - бывает, что "чисто юридическая специфика" остается в договоре. И предметом договора является сам SLA, содержащий, в свою очередь, всю "специфику процесса".
ПОРЯДОК - ПЕРВЫЙ ЗАКОН НЕБЕС!
Ещё раз можно сделать вывод, что для того чтобы добиться успеха и при этом не иметь проблем, или иметь их в минимальном количестве, надо
1) вникать в суть задачи;
2) детализировать задачу;
3) грамотно описать этапы;
4) четко следить за выполнением этих этапов.
Думаю, что такой подход будет полезен не только при написании ТЗ, но и во многих жизненных ситуациях!
PS Вспомнил ещё одно изречение - "Порядок бьёт класс!"
Ещё раз можно сделать вывод, что для того чтобы добиться успеха и при этом не иметь проблем, или иметь их в минимальном количестве, надо
1) вникать в суть задачи;
2) детализировать задачу;
3) грамотно описать этапы;
4) четко следить за выполнением этих этапов.
Думаю, что такой подход будет полезен не только при написании ТЗ, но и во многих жизненных ситуациях!
PS Вспомнил ещё одно изречение - "Порядок бьёт класс!"
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Какие этапы прописывать в договоре