Здравствуйте, Oliver, Вы писали:
O>Привет всем,
O>Какова роль подробного технического задания в проектеразработки не маленькой системы?
O>Если проль решающая и проект 100% ждет большая задержка срока, в лучшем случае, в худшем — провал. Как тогда можно исправить ситуацию, заниямая при этом должность программиста?
O>Я буду очень благодарен за любой фитбэк.
O>Успешной недели!
Роль программиста — реализовать согласно некоторому описанию, из которого однозначно можно получить продукт.
Если ТЗ формулирует функционал неоднозначно, я считаю возможны следующие варианты — вернуть ТЗ на доработку вместе с замечаниями к нему, если аналитик возмущается (бывает и такое) — начинаешь сам дописывать ТЗ и требовать, чтобы это было оформлено как документ.
Затем требуешь, чтобы приемка велась согласано этому документу, и если находятся разногласия, то требуешь внесения изменений в ТЗ, и соответственно выход новых версий ТЗ. В случае, если захотят тебя сделать крайним при задержке сроком или провале, ты говоришь о количестве версий ТЗ, которые вышли за время разработки (это все задокументировано), что сказалось и на времени разработки, и на её качестве. Все разговоры с аналитиком надо переводить в электронную почту, чтобы в случае чего это можно было обнародовать тем, кто начнет на тебя валить все проблемы.
Сделать программера крайним это очевидно, программист же должен свою задницу прикрывать.
Я смог проработать по такой схеме 3 месяца, потом послал все нах** и уволился. Придурки...
Остальным же программерам почему то было пох, что их делают крайними, я с этим мириться не хотел
Квалификация аналитиков оставляла желать лучшего, программисты же были люди довольно подкованными, просто несправедливая ситуация, наступившая прежде всего из-за попустительства менеджеров, которые уже совсем нихрена не хотели делать, или просто не знали что делать из-за недостаточной квалификации.
Здравствуйте, captainPower, Вы писали:
O>>Какова роль подробного технического задания в проектеразработки не маленькой системы?
O>>Если проль решающая и проект 100% ждет большая задержка срока, в лучшем случае, в худшем — провал. Как тогда можно исправить ситуацию, заниямая при этом должность программиста?
P>Роль программиста — реализовать согласно некоторому описанию, из которого однозначно можно получить продукт.
P>Если ТЗ формулирует функционал неоднозначно, я считаю возможны следующие варианты — вернуть ТЗ на доработку вместе с замечаниями к нему, если
...
в общих словах — все верно с позиции "крайнего программиста".
в качестве контрппозиции я могу сказать, что ленивый программист будет долго гонять тз на доработку.
до тех пор, пока у него не появиться желание что-нибудь поделать.
поделав что-нибудь, он опять свалит все на некачественное тз.
ну что мне туда вписывать фразы типа "девелопер должен приходить на работу трезвым и каждый день".
или без этого он "ни за что не отвечает" ???...
ладно. утрирую.
прямо сейчас у меня тима нет. но опыт подобных конфликтов — есть обширный.
во
Здравствуйте, Oliver, Вы писали:
[offtop]
O>Я буду очень благодарен за любой фитбэк.
фитбэк — толстая задница, мэй би фиДбэк? или все-таки опечатка по Фрейду
[/offtop]
Здравствуйте, serg_fork, Вы писали:
_>фитбэк — толстая задница, мэй би фиДбэк? или все-таки опечатка по Фрейду
Наверное толстая задница фэтбэк
хотя я увлекаюсь психологией. и не прочь бынабрать еще кг 15 мышечной массы
чирс
Здравствуйте, captainPower, Вы писали:
P>Роль программиста — реализовать согласно некоторому описанию, из которого однозначно можно получить продукт.
P>Если ТЗ формулирует функционал неоднозначно, я считаю возможны следующие варианты — вернуть ТЗ на доработку вместе с замечаниями к нему, если аналитик возмущается (бывает и такое) — начинаешь сам дописывать ТЗ и требовать, чтобы это было оформлено как документ.
P>Затем требуешь, чтобы приемка велась согласано этому документу, и если находятся разногласия, то требуешь внесения изменений в ТЗ, и соответственно выход новых версий ТЗ. В случае, если захотят тебя сделать крайним при задержке сроком или провале, ты говоришь о количестве версий ТЗ, которые вышли за время разработки (это все задокументировано), что сказалось и на времени разработки, и на её качестве. Все разговоры с аналитиком надо переводить в электронную почту, чтобы в случае чего это можно было обнародовать тем, кто начнет на тебя валить все проблемы.
P>Сделать программера крайним это очевидно, программист же должен свою задницу прикрывать.
P>Я смог проработать по такой схеме 3 месяца, потом послал все нах** и уволился. Придурки...
P>Остальным же программерам почему то было пох, что их делают крайними, я с этим мириться не хотел Квалификация аналитиков оставляла желать лучшего, программисты же были люди довольно подкованными, просто несправедливая ситуация, наступившая прежде всего из-за попустительства менеджеров, которые уже совсем нихрена не хотели делать, или просто не знали что делать из-за недостаточной квалификации.
Я полностью с Вами согласен. В данный момент наблюдаю такую ситуацию. пока просто наблюдаю.
Свалить на меня ответственность за срыв майлстоуна пытались, но я вовремя перкратил попытки еще когда начинался проект. Я тогда сразу увидел такую склонность в своем тим лиде.
Здесь проблема еще и с заказчиком — 80%. Не может предоставить толком информацию о системе. Бизнес аналитика нет как с нашей, так и с их стороны, чтобы провести сбор информации о буд системе.
Спасибо за фидбэк. Я думаю проект провалится, так как времени осталось мало.
