Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 25
как неоднократный составитель ТЗ и также неоднократный исполнитель (не своих ТЗ) могу сказать одно — программист не может писать ТЗ ибо он реализует его, а не ставит задачу…
а заказчики со своей стороны зачастую под аббревиатурой ТЗ понимают «точка зрения», а не «техническое задание»… отсюда и все проблемы…
а заказчики со своей стороны зачастую под аббревиатурой ТЗ понимают «точка зрения», а не «техническое задание»… отсюда и все проблемы…
Без программистов тут сложно обойтись. Во-первых такой «спец.должности» просто никто не держит, типа как «составитель ТЗ».
Кроме того, кто же лучше чем разработчик, знает аспекты, и может хотя бы оценить сложность проблемы… Стоит или не стоит в нее ввязываться, и т.п. Заказчик конечно хочет чтобы ему сделали «космический корабль», а задача составителя ТЗ убедить его в том, что ему хватит и автомобиля на ближайшие пару-тройку лет.
Кроме того, кто же лучше чем разработчик, знает аспекты, и может хотя бы оценить сложность проблемы… Стоит или не стоит в нее ввязываться, и т.п. Заказчик конечно хочет чтобы ему сделали «космический корабль», а задача составителя ТЗ убедить его в том, что ему хватит и автомобиля на ближайшие пару-тройку лет.
у «составителя ТЗ» должны быть минимальные знания, хотя нет, понятия программирования… а программисты от исполнителя должны тесно сотрудничать с заказчиком при составлении ТЗ, чтобы потом каждому было понятно что заказывалось и что решилось…
P.S. сам работаю инженером на предприятии over8k персонала и ни разу не видел, чтоб программист писал ТЗ… у нас еще руководство говорит, что плох тот инженер, который ТЗ писать не умеет…
P.S. сам работаю инженером на предприятии over8k персонала и ни разу не видел, чтоб программист писал ТЗ… у нас еще руководство говорит, что плох тот инженер, который ТЗ писать не умеет…
еще раз повторюсь — если исполнитель диктует правила решения задачи, то не факт, что на выходе будет желаемый продукт… есть заказчик, есть исполнитель, по середине они должны дойти консенсуса ибо задача не будет решена или решена через костыли…
В этом и беда, что ТЗ мало того, что считается точкой зрения, которую в любой момент можно поменять, так еще и ставится, исходя из малопонятных критериев. И решить это можно, может быть, только очень тесным взаимодействием представителей заказчика и исполнителя, когда все будет 100 раз уточнено компетентными людьми. И записано в договоре и приложениях к нему (хотя, наверное, он тогда получится ужасно огромным).
Без программистов тут сложно обойтись. Во-первых такой «спец.должности» просто никто не держит, типа как «составитель ТЗ».
Вы слышали про бизнес-аналитиков? А про системных аналитиков?
Конечно. В идеальном мире, когда у заказчика есть желание нанять аналитика для себя со стороны, а этот аналитик бы изучил бизнес-процессы и предоставил оформленные требования — звучит логично и хорошо. Но кто его нанимает? Последний наш заказчик — это некий банк. Сотрудники его IT отдела выступают как аналитики, и ставят задачи (что хотят получить). Мы с ними общаемся, предлагаем варианты решения. Мы знаем что мы можем сделать «малой кровью», они знают «в общих чертах» что хотят получить. Почему именно «малой кровью»? Да потому что оплачивать рыночную стоимость человеко-часа программиста они не готовы. Месяц-два-три (2000 уе на 1 человека) — вылетает круглая сумма. Даже для банка.
Вы всерьез сейчас это пишите? Потому что складывается впечатление, что вы бредите. Как вы реализуете проекты по кастомизации без собственных аналитиков? Единственный вариант — у вас очень маленькие проекты. В противном случае я не понимаю, как человек, читающий хабр и занимающийся кастомизацией, не знает об одной из ключевых ролей в ИТ-проектах.
Ошибки на этапе формирования скоупа и детализации задач — самые дорогие. Так что любой мало-мальски серьезный проект окупает хотя бы 1 аналитика, хотя бы part-time, хотя бы с совмещением ролей, хотя бы только на начальном этапе
Ошибки на этапе формирования скоупа и детализации задач — самые дорогие. Так что любой мало-мальски серьезный проект окупает хотя бы 1 аналитика, хотя бы part-time, хотя бы с совмещением ролей, хотя бы только на начальном этапе
Серьезно. Проекты очень разные (маленькие или большие — субъективный вопрос), и заказчики тоже. Хотите «документооборот» на 10 пользователей? Из коробки система может стоить...345 $. Это уже кое-что, для небольшого бизнеса. Нужно автоматизировать 500 пользователей? Это может стоить уже 26000 $. Как бы «миллион» никто не хочет выкладывать, людям нужны результаты, а деньги считают и экономят все.
Ну о чем и речь — очень маленькие проекты
В очень маленьких проектах, где ставится коробка, не может быть доработок. Как только появляется допиливание системы под заказчика, должны появиться ТЗ и аналитик, иначе вы будете попадать на деньги и сроки.
Ну и к тому же не надо формировать в голове клиента мысль, что он может отказаться от ТЗ и сэкономить на этом пару тысяч. Т.е. или ТЗ и доработка системы, или вообще никаких работ.
Ну и к тому же не надо формировать в голове клиента мысль, что он может отказаться от ТЗ и сэкономить на этом пару тысяч. Т.е. или ТЗ и доработка системы, или вообще никаких работ.
На самом деле у нас понятие «допиливание» — это не изменение существующего функционала. Весь коробочный функционал остается, а новое либо вписывается культурно (как новшество, которое будет полезно всем, либо новый модуль, новый плагин). Платформа при этом не меняется, и заказчик доволен.
По поводу аналитиков — конечно, такой человек необходим в любом случае, и он есть. Просто роль аналитика обычно выполняет человек с нашей стороны, а также есть один или несколько человек со стороны заказчика, которые объясняют, что хотят получить, и т.п.
По поводу аналитиков — конечно, такой человек необходим в любом случае, и он есть. Просто роль аналитика обычно выполняет человек с нашей стороны, а также есть один или несколько человек со стороны заказчика, которые объясняют, что хотят получить, и т.п.
«Правильный подход» на практике практически невозможно реализовать.
Попробуйте встать на сторону Заказчика.
Зачем ему ваш коробочный продукт, если он не выполняет нужных ему функций?
Тут либо вы его сможете убедить, что ему эти функции не нужны (в вашем продукте есть другой метод решения задачи), либо проще найти другой продукт, где эти функции уже есть.
Если же предложенная функция действительно расширит полезный функционал продукта и пригодится другим клиентам, то ее нужно реализовать бесплатно. А если нет — то и за деньги ее вносить не стоит.
Попробуйте встать на сторону Заказчика.
Зачем ему ваш коробочный продукт, если он не выполняет нужных ему функций?
Тут либо вы его сможете убедить, что ему эти функции не нужны (в вашем продукте есть другой метод решения задачи), либо проще найти другой продукт, где эти функции уже есть.
Если же предложенная функция действительно расширит полезный функционал продукта и пригодится другим клиентам, то ее нужно реализовать бесплатно. А если нет — то и за деньги ее вносить не стоит.
На практике поставка ПО и услуги по внедрению это и так разные договоры.
Другое дело, что многие вендоры поставляют платформу за минимум денег (иногда бесплатно), поэтому крайне сложно «продать» лицензии.
Другое дело, что многие вендоры поставляют платформу за минимум денег (иногда бесплатно), поэтому крайне сложно «продать» лицензии.
К автору дофига вопросов:
1) Вы в юридические тонкости вникали? Договоры на услуги и поставку ПО — разные по сути, так что нет смысла писать об этом.
2) Почему просто не договориться на предоплату? Заказчик, заплатив денег, чувствует свою ответственность за результат и внедрение идет гораздо более гладко.
3) Почему бы вместо большого ТЗ не использовать итеративный подход? То есть фиксировать объем работ на небольшой промежуток времени, а после внедрения этого куска развивать?
4) Почему бы не убрать фиксированную цену с сайта, чтобы не создавать ложные ожидания? Или сформулировать это как нижнюю планку цены? Или указать реальную цену внедрения с учетом доработок?
1) Вы в юридические тонкости вникали? Договоры на услуги и поставку ПО — разные по сути, так что нет смысла писать об этом.
2) Почему просто не договориться на предоплату? Заказчик, заплатив денег, чувствует свою ответственность за результат и внедрение идет гораздо более гладко.
3) Почему бы вместо большого ТЗ не использовать итеративный подход? То есть фиксировать объем работ на небольшой промежуток времени, а после внедрения этого куска развивать?
4) Почему бы не убрать фиксированную цену с сайта, чтобы не создавать ложные ожидания? Или сформулировать это как нижнюю планку цены? Или указать реальную цену внедрения с учетом доработок?
А в чем сложность работы по одному договору? По договору проводится передача неисключительных прав на использование ПО (без НДС, в соответствии с лицензионным соглашением, которое является приложением к договору) и оказываются услуги (с НДС, в соответствии с календарным планом\техзаданием, которые тоже являются приложениями к договору).
Условия оплаты прописываются отдельно для каждой позиции договора: лицензии, работы, поставка товаров и т.д.
Условия закрытия — аналогично.
Реальных причин не работать в рамках одного договора нет, кроме пожеланий клиента и упертости юристов.
Если же действительно есть какие-то юридические тонкости, связанные с разделением лицензии и работ в два договора — прошу вас дать на них ссылку для изучения.
Условия оплаты прописываются отдельно для каждой позиции договора: лицензии, работы, поставка товаров и т.д.
Условия закрытия — аналогично.
Реальных причин не работать в рамках одного договора нет, кроме пожеланий клиента и упертости юристов.
Если же действительно есть какие-то юридические тонкости, связанные с разделением лицензии и работ в два договора — прошу вас дать на них ссылку для изучения.
Разбить по календарному плану график оплат возможно, у нас был такой случай, когда заказчик покупал лицензии не сразу например 500 штук, а по 50 в течении 10 месяцев. Это было удобно, и нам, и ему, и главное мы видели, что он готов работать серьезно. Если бы все такие были заказчики, жизнь была бы намного проще.
Глянул сайт, простите но это ужас…
1) шаблон на жумле смотрится дешево
2) Вариантов покупки слишком много
3) UI вашей системы смотрится как говно
4) Десктопные клиенты — говно в квадрате
Искренне надеюсь что подобные системы сдохнут ка можно скорее.
1) шаблон на жумле смотрится дешево
2) Вариантов покупки слишком много
3) UI вашей системы смотрится как говно
4) Десктопные клиенты — говно в квадрате
Искренне надеюсь что подобные системы сдохнут ка можно скорее.
Сайт FossDoc конечно старенький, и мы тоже хотим его переделать. По поводу продуктов — тут тоже был большой вопрос: с одной стороны мы хотели дать людям выбор, да еще и возможность «отметить» галочками нужные им модули. Однако, такая практика привела к тому, что нам скорее позвонят и спросят, какой модуль им нужен, чем выберут сами.
Для FossLook мы уже отказались от идеи «выбери модули», и отобрали в него только самое необходимое, и цена там зависит только от числа клиентских мест — вычислить очень просто, и без вариантов.
Действительно, наши клиентские места долгое время были только десктопными, но сейчас есть и веб-доступ.
Для FossLook мы уже отказались от идеи «выбери модули», и отобрали в него только самое необходимое, и цена там зависит только от числа клиентских мест — вычислить очень просто, и без вариантов.
Действительно, наши клиентские места долгое время были только десктопными, но сейчас есть и веб-доступ.
1) Объявляется тендер. Туда «пихается» все — от поставки, до «в общем плане» например «Автоматизировать вот это»
2) договор сделают один — сам хотел бы разделить их на два, но нет (все умные, хотят «одним куском»)
3) итеративный подход хорошая штука, но деньги «выделяют» обычно один раз в год. И директор ИТ-департамента ДВА-три и более раз не ходит за деньгами. Так бы было чудно — спокойно запустили в работу систему «как есть» (из коробки), потом спокойно согласовали первый бизнес-процесс, оценили-заплатили-внедрили. Потом второй, десятый — все окей. Но так ни разу не делали — именно по причине что «наш клиент не может так платить»
4) договор должен быть закрыт — предоплата это да, допустим 30%. Но если это превращается в «резину» которая на годик, ничего хорошего в этом нет.
5) Доработки включают в договор… Но это «априори». Все равно что вас спросили «ааа… в здании нужен ремонт. Оцените, плиз, сразу, и да — стройматериалы тоже ваши». А вы такой — «Так он же очень разный бывает… и такой и сякой». А вам заказчик «Нуу… давайте примерно… как-нибудь этак-так». «И да, у нас бюджет ограничен в этом году… только вот в пределах этого»
2) договор сделают один — сам хотел бы разделить их на два, но нет (все умные, хотят «одним куском»)
3) итеративный подход хорошая штука, но деньги «выделяют» обычно один раз в год. И директор ИТ-департамента ДВА-три и более раз не ходит за деньгами. Так бы было чудно — спокойно запустили в работу систему «как есть» (из коробки), потом спокойно согласовали первый бизнес-процесс, оценили-заплатили-внедрили. Потом второй, десятый — все окей. Но так ни разу не делали — именно по причине что «наш клиент не может так платить»
4) договор должен быть закрыт — предоплата это да, допустим 30%. Но если это превращается в «резину» которая на годик, ничего хорошего в этом нет.
5) Доработки включают в договор… Но это «априори». Все равно что вас спросили «ааа… в здании нужен ремонт. Оцените, плиз, сразу, и да — стройматериалы тоже ваши». А вы такой — «Так он же очень разный бывает… и такой и сякой». А вам заказчик «Нуу… давайте примерно… как-нибудь этак-так». «И да, у нас бюджет ограничен в этом году… только вот в пределах этого»
Знакомо. Госзаказчик. Договора все подписываются в ноябре. Закрыты должны быть декабрем. :)
И хоть ты тресни… :)
И хоть ты тресни… :)
Вот именно. Такие «номера» в ходу не только у гос.заказчиков, но и у частных организаций тоже. А какой калибр проектов был у вас, например? Хотя бы в общих чертах — что примерно внедряли, на сколько пользователей, много ли было бизнес-процессов? Очень интересно было бы узнать сколько времени потратили на составление ТЗ, или сколько прошло времени с момента «как начали» до момента «закрыли договор и получили деньги».
Суммы не скажу, не в курсе.
Бизнес-процессов никаких.
Установка, монтаж оборудования. Установка, настройка ПО, обучение персонала на месте.
ТЗ по накатанной рыбе, причем оно от продукта к продукту отличается не сильно, все в самых общих чертах, абстрактно.
Начнешь делать подробно и потом упираться — себе дороже выйдет, причину не подписать акт всегда найти можно при желании.
Бизнес-процессов никаких.
Установка, монтаж оборудования. Установка, настройка ПО, обучение персонала на месте.
ТЗ по накатанной рыбе, причем оно от продукта к продукту отличается не сильно, все в самых общих чертах, абстрактно.
Начнешь делать подробно и потом упираться — себе дороже выйдет, причину не подписать акт всегда найти можно при желании.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Проблемы при внедрении и продаже систем электронного документооборота