угадал, однако
Ставь плюс и иди дальше.
Главное - ни за что на свете не называйте его обезьяной. Он этого не любит.
скорее, чаще всего
братья реакторчане, кто что может посоветывать почитать о бэк энде
после выполнения задания все работники пришли посмотреть
Бэта тест невидимой двери.
У меня примерно такая же рожа будет, когда я выйду на работу после месячного отпуска...
просто у исполнителей по жизни бомбит, потому что клиентское ТЗ не соответствуют их выдуманным стандартам. Даже если оно соответвует существующему стандарту, ибо ныть что клиент тупой, проще, чем не косячить и делать уточнения.
хит месяца :
- начальник производства написал ТЗ
- аналитик изменил одну табличку, отправил на согласование
- начальник производства забыл за неделю, что ТЗ писал сам - заявил, что табличка заебись, а вот все остальное говно и термины такие на производстве вообще никто не использует.
- начальник производства написал ТЗ
- аналитик изменил одну табличку, отправил на согласование
- начальник производства забыл за неделю, что ТЗ писал сам - заявил, что табличка заебись, а вот все остальное говно и термины такие на производстве вообще никто не использует.
ТЗ (Техническое задание) - записаное на бумаге, описание того что надо получить заказчику.
Проблема в том, что заказчик сам не понимает (не может объяснить) что ему нужно, и по каким принципам оно должно работать.
Обычно ТЗ пишут разработчики (исполнители) - САМИ ДЛЯ СЕБЯ И ПОД СЕБЯ!
Проблема в том, что заказчик сам не понимает (не может объяснить) что ему нужно, и по каким принципам оно должно работать.
Обычно ТЗ пишут разработчики (исполнители) - САМИ ДЛЯ СЕБЯ И ПОД СЕБЯ!
Предварительное ТЗ вполне может написать и заказчик, но перед началом разработки на его основе менеджер/аналитик, общаясь с заказчиком и с будущими разработчиками приводит ТЗ к божескому финальному виду.
Непосредственно разработчики сами себе ТЗ пишут разве что в совсем мелких проектах. Разработчики не понимают специфики бизнес-требований заказчика, заказчик ничего не знает о проектировании ПО, то есть без тесного взаимодействия двух сторон нормального ТЗ не родить.
Непосредственно разработчики сами себе ТЗ пишут разве что в совсем мелких проектах. Разработчики не понимают специфики бизнес-требований заказчика, заказчик ничего не знает о проектировании ПО, то есть без тесного взаимодействия двух сторон нормального ТЗ не родить.
Угу, а потом думаешь, как это сделать, потому что зачастую там "взаимоисключающие параграфы"
Закинул гифку на добавление на www.morekoda.ru, а то что-то давненько там ничего нового не появлялось )
Отличный комментарий!