По-моему — Вы совершенно неправильно
строите отношения с начальством и
руководством фирмы:
1. Существуют только 2 вида нормальных отношений:
— работа на окладе + бонусы за проекты
В этом случае оговаривается:
стандартная зарплата (именно эти цифры указываются в объявлениях по найму);
система бонусов за успехи и, возможно, штрафов за неудачи.
Причем штраф накладывается решением руководства организации обязательно после официально состоявшегося "разбора полетов".
Если Вы работаете так, то ТЗ Вам не нужно, Вы делаете то, что Вам говорят и прекрасно себя чуствуете.
— работа по договору.
Вы оговариваете фронт работ и их финансирование.Но в этом случае Вы должны обязательно иметь ТЗ и вести четкий протокол диалога с Заказчиком.Протокол — не обязательно каждый раз заверенная обеими сторонами бумажка. Чаще всего достаточно обычной подшивки электронных писем, в которых точно и внятно оговариваются проблемы, решения и согласие на них. Но "забытых", не оговоренных хотя бы в письмах, проблем и решений по существенным вопросам быть не должно.
Это нужно прежде всего Вам. Дело в том, что никто не любит платить деньги. В природе Заказчика сваливать свои ошибки и недочеты в постановке задачи на Исполнителя и платить ему по минимуму. Если Вы имеете ТЗ и ведете протокол Ваших взаимоотношений,то Вы в любой момент можете устроить "разбор полетов" и доказать, в чем виноваты Вы, а в чем Заказчик предъявляет к Вам необоснованные претезии. На словах такие вещи не доказываются — Заказчик всегда может сказать, что его не так поняли, либо тогда он не это имел ввиду, либо вообще отказаться от прошлого разговора.
2. Любая другая "комбинированная" схема отношений ведет только к тому, что Вы вообще рискуете ничего не получить.
Иногда Исполнители вынуждены идти на такие схемы (например,для получения дополнительной квалификации). Однако Вы должны отдавать себе отчет, на что подписываетесь, и должны быть готовы к тому, что в случае чего придется менять контору
3. Вы писали: _>4) Несогласие начальников в основной фирме с качеством выполнения работы и ценой за эту работу. В основном, как по мне, так необоснованные. Типа вот ты это сделал, а чего, сам не знал, что при этом надо было еще сделать это это и это. Мы думали, что ты сам знаешь, это же очевидно, а ты не сделал то, что надо было давно сделать, поэтому бабок не получишь не за то что сделал, ибо сделал плохо, ни за то, что по этой задаче будешь еще делать, ибо это уже давно сделать надо было.
Если Вы работаете по схеме 1, то цена — вообще не Ваша проблема и не проблема Ваших начальников: Вы имеете оклад — Вы должны его получить — и точка. Если с этим возникают проблемы, то нужно менять контору — ничего хорошего Вас в дальнейшем не ждет.
Если Вы работаете по схеме 2, то все такие претензии по большей части отсылаются к протоколу и ТЗ. Ваша задача — УМЕТЬ В ЛЮБОЙ МОМЕНТ ДОКАЗАТЬ, что Вы сделали ИМЕННО ТО, что Вам ЗАКАЗЫВАЛИ, а что они при этом думали — это ИХ ПРОБЛЕМЫ.
4. Вы писали: _> Куда идти дальше и как это решить? Очень желательно найти компромисс и решить мирно.
По небольшим дополнительным работам можно и нужно договориться.
Но в денежных делах следует вести себя жестко. Начальники должны твердо знать, что либо они выплатят все, что положено,либо не получат ничего и потеряют Вас как специалиста. В противном случае Вы не выберетесь из Вашей ситуации никогда.
Как объяснить это руководству — вопрос ситуации и такта Ваших взаимоотношений. Но объяснить необходимо.Кстати, не стесняйтесь сказать об этом прямо — это нормальная ситуация. Если у Вас вменяемые начальники, то такой разговор не приведет ни к какому конфликту, лишь добавит Вам дополнительные очки в их глазах.
Если же это зашло далеко, то ищите другую контору. Можете, кстати, искать другую контору параллельно с переговорами с начальниками. Многие именно так и поступают.
5. Хорошее ТЗ написать несложно.
В ТЗ не нужно описывать детали и продумывать все точно, оговорите только общий контур разработки.Под деталями здесь я понимаю моменты, на реализацию тех или иных решений по которым уходит минимальное время (не более 1 — 2 недель).
Все остальные решения следует оговаривать в ТЗ и техническом проекте.Полезно к ТЗ приложить схему бизнес-процессов и наброски ключевых скриншотов будущей системы (нарисуйте их, например, в MS Visio). Не стесняйтесь рисовать побольше картинок и схем — это сделает текст более понятным и Вам и Вашим начальникам, которые будут это ТЗ утверждать.
Основное требование к ТЗ одно — оно должно убедить Вас, что, утвердив ТЗ, Вы с начальниками ПРАВИЛЬНО ПОНЯЛИ друг друга — и по основным моментам работ проблем по разработке, приемке и оплаты не будет.
3 года работы в фирме.
Этапы
1) Разработка ПО для собственных нужд фирм (автоматизация деятельности) Работа на окладе. Т.З. не оговаривается совсем, или только в краткой усной форме.
Начался кризис первый, что денег мало. Но тут подоспел второй пункт и стало легче.
2) Продажа этого ПО по другим "знакомым фирмам". Работа окладе.
С другими фирмами сдельно.
3) Переход на сдельную работу после появления нескольких фирм-заказчиков. Разработка системы сдельной оплаты.
Для определения стоимости после выполения работы предоставляется отчет о проделанной за месяц работе на каждую фирму.
Т.З. не оформляется, только кратко в устной форме.
Вообщем-то тут меня все устраиват, и их все устраивает. У меня полная заинтересованность в увеличении производительности работы. Соответсвенно и зарплата увеличилась в 2-3 раза.
Но проходит полгода И расцвел кризис.
4) Несогласие начальников в основной фирме с качеством выполнения работы и ценой за эту работу. В основном, как по мне, так необоснованные. Типа вот ты это сделал, а чего, сам не знал, что при этом надо было еще сделать это это и это. Мы думали, что ты сам знаешь, это же очевидно, а ты не сделал то, что надо было давно сделать, поэтому бабок не получишь не за то что сделал, ибо сделал плохо, ни за то, что по этой задаче будешь еще делать, ибо это уже давно сделать надо было.
Хорошее Т.З. писать долго, сложно, никто толком не умеет и некому. Хотя, я вообщем-то представляю, как это писать.
Куда идти дальше и как это решить? Очень желательно найти компромисс и решить мирно.
b> Здравствуйте, kochmin_alexandr, Вы писали:
b> _> Куда идти дальше и как это решить? Очень желательно найти компромисс b> и решить мирно.
b> писать. ТЗ и договор, или хотя бы, что-то типа договора: "с одной b> стороны сделать в проге то-то, с другой стороны заплатить столько-то"
Да, примерно так. Но проблемы.
вот это "сделать то-то" надо писть достаточно подробно. Т.е. как быть в случае, если не написано. И кто это будет писать, и за чей счет.
И вот это "заплатить столько то" кто будет считать. Сейчас оплата идет по факту по затраченному времени. А если считать по ТЗ, то будет неточно, и будет риск с обоих сторон. И надо закладываться на риск.
В результате будет более большие деньги за разработку того же.
_>Да, примерно так. Но проблемы. _>вот это "сделать то-то" надо писть достаточно подробно. Т.е. как быть в случае, если не написано. И кто это будет писать, и за чей счет.
Пишешь ты, подтверждает заказчик, ставите подписи.
Любое требование вне ТЗ подразумевает изменение бюджета и/или сроков исполнения.
_>И вот это "заплатить столько то" кто будет считать.
Это считаешь ты. Затем споришь с заказчиком, т.к. он возможно будет не согласен.
Сейчас оплата идет по факту по затраченному времени. А если считать по ТЗ, то будет неточно, и будет риск с обоих сторон. И надо закладываться на риск. _>В результате будет более большие деньги за разработку того же.
Т.е. как по затраченному времени? Т.е. делал 100 часов получил 500$, а делал 50 часов — 250?
Создание ТЗ и плана разработки облегчает работу и уменьшает вероятность невыплаты денег, т.к. есть официальный документ. Вообще, нас в универе так учили — сначала анализ потребностей, затем концептуалная модель, спецификация требований и , наконец, эскизный проект. И все это документы, имющие юридическую силу.
М> Здравствуйте, kochmin_alexandr, Вы писали:
М> _>Да, примерно так. Но проблемы. М> _>вот это "сделать то-то" надо писть достаточно подробно. Т.е. как быть М> в случае, если не написано. И кто это будет писать, и за чей счет.
М> Пишешь ты, подтверждает заказчик, ставите подписи. М> Любое требование вне ТЗ подразумевает изменение бюджета и/или сроков М> исполнения.
понятно. буду учить заказчиков. Сами напросились.
М> _>И вот это "заплатить столько то" кто будет считать.
М> Это считаешь ты. Затем споришь с заказчиком, т.к. он возможно будет не М> согласен.
Понятно.
М> Сейчас оплата идет по факту по затраченному времени. А если считать по М> ТЗ, то будет неточно, и будет риск с обоих сторон. И надо закладываться М> на риск. _>В результате будет более большие деньги за разработку того М> же.
М> Т.е. как по затраченному времени? Т.е. делал 100 часов получил 500$, а М> делал 50 часов — 250?
да. Примерно так. Но с повышающими коэффицинтами за качество. Который неочень и понятно, как применять.
М> Создание ТЗ и плана разработки облегчает работу и уменьшает вероятность невыплаты денег, т.к. есть официальный документ. М> Вообще, нас в универе так учили — сначала анализ потребностей, затем М> концептуалная модель, спецификация требований и , наконец, эскизный М> проект. И все это документы, имющие юридическую силу.
Я делал по-другиму. Примерно как учит XP. минимизация расходов заказчика+гибкость+работа с постоянно меняющимися требованиями, когда заказчик сам не знает чего хочет.
И это было правильно, это полностью подходило в данных условиях. Но вот заказчику захотелось побузить, и надо ему показать более другие метода работы.
Здравствуйте, kochmin_alexandr, Вы писали:
_>да. Примерно так. Но с повышающими коэффицинтами за качество. Который неочень и понятно, как применять.
Качество определяется довольно просто — выполнение требований в указанные сроки и в намеченный бюджет. Следовательно, ТЗ необходимо. Про то, как писать ТЗ можно посмотреть ГОСТ и документ IEEE
М> Здравствуйте, kochmin_alexandr, Вы писали:
М> _>да. Примерно так. Но с повышающими коэффицинтами за качество. Который М> неочень и понятно, как применять.
М> Качество определяется довольно просто — выполнение требований в М> указанные сроки и в намеченный бюджет. Следовательно, ТЗ необходимо. Про М> то, как писать ТЗ можно посмотреть ГОСТ и документ IEEE
хорошо. Понятно.
А за чем чей делается ТЗ?
А как быть с ТЗ на мелкие доработки?
А как быть если заказчик сам точно не знает, чего хочет?
А есть другие подходы к этому делу?
А как быть, если один захочет работать как раньше, а второй по четкой постановке задачи? (Заказчиков несколько по одному продукту).
Здравствуйте, kochmin_alexandr, Вы писали:
_>А за чем чей делается ТЗ? _>А как быть с ТЗ на мелкие доработки? _>А как быть если заказчик сам точно не знает, чего хочет?
_>А есть другие подходы к этому делу? _>А как быть, если один захочет работать как раньше, а второй по четкой постановке задачи? (Заказчиков несколько по одному продукту).
Ну похоже тебе пора заводить менеджера, аналитика, технического писателя, тестировщика, крышу, только думаю, что после этого будет у тебя денюжков меньше, чем на первом году раболты за оклад.
b> Ну похоже тебе пора заводить менеджера, аналитика, технического b> писателя, тестировщика, крышу, только думаю, что после этого b> будет у тебя денюжков меньше, чем на первом году раболты за оклад.
ага. Пора. Ибо портфель сейчас забит заданиями на несколько месяцев вперед.
Так что меньше не будет.
_>хорошо. Понятно.
_>А за чем чей делается ТЗ?
За чей счет? Вся документация — неотъемлимая часть программной системы, значит входит в стоимость
_>А как быть с ТЗ на мелкие доработки?
Решай сам.
_>А как быть если заказчик сам точно не знает, чего хочет?
Так всегда. Надо готовиться к этому и особо не переживать, выработать подходящую стратегию
_>А есть другие подходы к этому делу?
_>А как быть, если один захочет работать как раньше, а второй по четкой постановке задачи? (Заказчиков несколько по одному продукту).
Не знаю
М> _>А как быть если заказчик сам точно не знает, чего хочет?
М> Так всегда. Надо готовиться к этому и особо не переживать, выработать М> подходящую стратегию
вот и была стратегия... Но чего-то она уперлась в кризис
Здравствуйте, kochmin_alexandr, Вы писали:
b>> Ну похоже тебе пора заводить менеджера, аналитика, технического b>> писателя, тестировщика, крышу, только думаю, что после этого b>> будет у тебя денюжков меньше, чем на первом году раболты за оклад.
_> ага. Пора. Ибо портфель сейчас забит заданиями на несколько месяцев вперед. _>Так что меньше не будет.
b> _> ага. Пора. Ибо портфель сейчас забит заданиями на несколько месяцев b> вперед. _>Так что меньше не будет.
b> О! Я слышу голос не мальчика, но мужа!
а ты как думал. И вот когда тут и так голова забита заданиями, тут захотелось еще и изменить организацию работы.
b> Куда резюме присылать?
все это поскипано, ибо немного не то, учитывая определенную тонкую специфику
S> Основное требование к ТЗ одно — оно должно убедить Вас, что, утвердив S> ТЗ, Вы с начальниками ПРАВИЛЬНО ПОНЯЛИ друг друга — и по основным S> моментам работ проблем по разработке, приемке и оплаты не будет.
а вот это понятно. Видимо именно так и будем работать.
SMSM -> "Re: отношения с заказчиком" :
S> Основное требование к ТЗ одно — оно должно убедить Вас, что, S> утвердив ТЗ, Вы с начальниками ПРАВИЛЬНО ПОНЯЛИ друг друга — и по
"Теперь ты понимаешь, зачем все-таки нужны бизнес-аналитики"(С) Мой
Yury Kopyl aka hrg | http://id.totem.ru | "Спам придумали боги в отместку
за наши молитвы."
Здравствуйте, kochmin_alexandr, Вы писали:
_>4) Несогласие начальников в основной фирме с качеством выполнения работы и ценой за эту работу. В основном, как по мне, так необоснованные. Типа вот ты это сделал, а чего, сам не знал, что при этом надо было еще сделать это это и это. Мы думали, что ты сам знаешь, это же очевидно, а ты не сделал то, что надо было давно сделать, поэтому бабок не получишь не за то что сделал, ибо сделал плохо, ни за то, что по этой задаче будешь еще делать, ибо это уже давно сделать надо было.
_>Хорошее Т.З. писать долго, сложно, никто толком не умеет и некому. Хотя, я вообщем-то представляю, как это писать. _> Куда идти дальше и как это решить? Очень желательно найти компромисс и решить мирно.
В такие ситуации я сам по молодости попадал. И видел как попадают другие. Ситуация типичная.
Причина разногласий — отсутствие техзадания. Про то что это долго и сложно — так если не написать, то еще дольше и сложнее выйдет.
В последних своих проектах я написал довольно много документов, разногласия были, но по сравнению с вашими просто смешные. На данный момент я таки рекомендую написать ТЗ, а также протокол разногласий. Как вы найдете компромисс с зказчиком — не знаю, но если не будете вести хотя бы простейшую проектную документацию, то будете снова и снова наступать на те же самые грабли.
Здравствуйте, kochmin_alexandr, Вы писали:
М>> Пишешь ты, подтверждает заказчик, ставите подписи. М>> Любое требование вне ТЗ подразумевает изменение бюджета и/или сроков М>> исполнения.
_>понятно. буду учить заказчиков. Сами напросились.
И это правильно. Между прочим, не обязательно писать ТЗ согласно ГОСТ. Проще и эффективнее писать функциональные требования. Это более простой по форме документ, экстракт из ТЗ без лишней воды. Лично я предпочитаю писать ФТ по методике Алистера Коберна. Вот здесь все толково описано:
1) Устраиваешь митинг с заказчиком, он излагает тебе свои требования, своё видение системы
2) Рисуешь Use-Case диаграммы для иллюстрации, описываешь каждый Use-Case на бумаге. Лично я стараюсь описать каждый use-case как можно более подробно, вплоть до перечисления списков и типов полей, например.
3) Показываешь результат заказчику. Делаешь корректировки под его диктовку. Задаешь многочисленные "Что если?" а "Почему?". Чем больше — тем лучше. Это самый важный этап. Своими вопросами ты помогаешь заказчику понять, чего же он хочет на самом деле. Возможно, ты предложишь ему свое, более эффективное решение. Вообще прими за аксиому: заказчик никогда не знает толком, чего он хочет, и жить станет намного проще.
4) Если возражений/дополнений нет — приступаешь к проектированию, иначе goto (2)
Ты удивишься, насколько сильно изменится постановка задачи по отношению к изначальной после нескольких таких итераций.
_>Я делал по-другиму. Примерно как учит XP. минимизация расходов заказчика+гибкость+работа с постоянно меняющимися требованиями, когда заказчик сам не знает чего хочет.
Многие техники XP работают великолепно, и их надо применять, но если твоя задача не только минимизация расходов заказчика, но и снижение себестоимости, то лучше на начальных стадиях разработки следовать RUP, то есть провести основательные исследования предметной области совместно с заказчиком.
Я использую смесь двух техник: RUP — на начальном этапе, XP — на этапе разработки, и очень доволен результатом.
Хотелось бы уточнить, что это за заказчик такой попался. Интересно, чем фирма занимается? Причины недовольства лежат на ладони. Фирмы почему-то очень не любят осознавать тот факт, что некоторые сотрудники практически не зависят от них материально и имеют, кроме основной работы, еще и "левак". Ну никак они не поймут, что это не они тебе делают одолжение — принимают на работу, а ты им оказываешь жизненно важные для них услуги. Без которых они загнутся скорее, чем ты, т.к. они набрали кредитов по самые уши и их надо отдавать с процентами, а у тебя есть всегда заначка на черный день и возможность уйти к другому заказчику. Таким образом, имеем дело с заблудившейся во времени где-то на уровне 1850-х годов фирмой. Единственный разумный совет — уйти. Добить взятый на себя заказ и уйти. Мне кажется, очень много фирм боятся чрезмерно "умных" сотрудников, особенно если фирма софтверная или связана так или иначе с ИТ. Лучше уже с рестораном каким-то работать или спиртзаводом — им главное, чтобы "оно" работало и приносило им пользу, а не чтобы было "лучше, чем у Билли". Да и смотрит такой заказчик на нашего брата скорее снизу вверх... Ну, а насчет "белой" зарплаты... Это наверное совковая инертность мышления, ну не вижу я причин, по которым "наемный работник" звучит гордо... Скорее наоборот. Еще, имхо, все налоги каждый должен платить сам и со своих доходов, вне зависимости от их источника — только от суммы, полученной определенным лицом за определенный период. Вот тогда все быстро перейдут на белую схему. Но это, видно, кому-то очень невыгодно...
Здравствуйте, kochmin_alexandr, Вы писали:
_>3 года работы в фирме. _>Этапы _>1) Разработка ПО для собственных нужд фирм (автоматизация деятельности) Работа на окладе. Т.З. не оговаривается совсем, или только в краткой усной форме. _>Начался кризис первый, что денег мало. Но тут подоспел второй пункт и стало легче. _>2) Продажа этого ПО по другим "знакомым фирмам". Работа окладе. _> С другими фирмами сдельно. _>3) Переход на сдельную работу после появления нескольких фирм-заказчиков. Разработка системы сдельной оплаты. _> Для определения стоимости после выполения работы предоставляется отчет о проделанной за месяц работе на каждую фирму. _> Т.З. не оформляется, только кратко в устной форме. _> Вообщем-то тут меня все устраиват, и их все устраивает. У меня полная заинтересованность в увеличении производительности работы. Соответсвенно и зарплата увеличилась в 2-3 раза. _>Но проходит полгода И расцвел кризис. _>4) Несогласие начальников в основной фирме с качеством выполнения работы и ценой за эту работу. В основном, как по мне, так необоснованные. Типа вот ты это сделал, а чего, сам не знал, что при этом надо было еще сделать это это и это. Мы думали, что ты сам знаешь, это же очевидно, а ты не сделал то, что надо было давно сделать, поэтому бабок не получишь не за то что сделал, ибо сделал плохо, ни за то, что по этой задаче будешь еще делать, ибо это уже давно сделать надо было.
_>Хорошее Т.З. писать долго, сложно, никто толком не умеет и некому. Хотя, я вообщем-то представляю, как это писать.
_> Куда идти дальше и как это решить? Очень желательно найти компромисс и решить мирно.
IMHO, слишком подробное ТЗ можно не писать, главное, чтобы в нем были отражены этапы, объемы работ и сроки. Также необходимо составить договор, в котором есть ссылка на ТЗ. Чтобы не произошло так, что ты все сделал, а заказчику не понравилось и тебе ничего не заплатили, нужно всю работу разбить не несколько этапов (одним из них может быть составление и согласование ТЗ). После завершения каждого этапа заказчик с тобой расплачивается.
только думаю, что после этого будет у тебя денюжков меньше, чем на первом году раболты за оклад. 
