LZ
Все в целом сводится к тому, что теории много. А практики и понимания нюансов и узких мест нет
Size: a a a
2021 March 22
PB
С железом похожая история, кстати. За себя могу сказать, что точно вел себя в начале пути аналогичным образом, "прыгал по галочкам". Вот сейчас главная проблема в том, что я не знаю, чего я не знаю :D
PB
Stackoverflow, кстати, сменился на аппноуты и книги. Может так и в софте
A
Витька Корнеев
без чёткого и исчерпывающего ТЗ - результат ХЗ
Малоприменимая мантра в реальности.
Как раз требование исчерпывающего ТЗ по пунктам - любимая фишка джуниоров. И на формирование полного и исчерпывающего ТЗ на простые задачи времени может уйти больше чем на ее решение.
Кроме того, утрясание вопросов со смежниками как правило лежит на плечах исполнителя .
Как раз требование исчерпывающего ТЗ по пунктам - любимая фишка джуниоров. И на формирование полного и исчерпывающего ТЗ на простые задачи времени может уйти больше чем на ее решение.
Кроме того, утрясание вопросов со смежниками как правило лежит на плечах исполнителя .
KA
Petr Belyaev
Stackoverflow, кстати, сменился на аппноуты и книги. Может так и в софте
Какой нафиг stackoverflow в железе?? Толку от electronics.stackexchange никакого.
PB
Честно, я сейчас даже не помню, что я там смотрел по железу :D
Еще же и по сям/питону постоянно что-то ищется. Может перемешалось уже
Еще же и по сям/питону постоянно что-то ищется. Может перемешалось уже
DF
Какой нафиг stackoverflow в железе?? Толку от electronics.stackexchange никакого.
А расскажите почему если не трудно ? Я сам не железячник
В
Малоприменимая мантра в реальности.
Как раз требование исчерпывающего ТЗ по пунктам - любимая фишка джуниоров. И на формирование полного и исчерпывающего ТЗ на простые задачи времени может уйти больше чем на ее решение.
Кроме того, утрясание вопросов со смежниками как правило лежит на плечах исполнителя .
Как раз требование исчерпывающего ТЗ по пунктам - любимая фишка джуниоров. И на формирование полного и исчерпывающего ТЗ на простые задачи времени может уйти больше чем на ее решение.
Кроме того, утрясание вопросов со смежниками как правило лежит на плечах исполнителя .
вот оно и плохо, что малоприменимая, особенно если заказчик сам не знает что хочет. а при наличии тз-можно по его пунктам предьявить результат. и если заказчик чего то не написал, то доработки уже з отдельные деньги и в новые сроки
PB
Витька Корнеев
вот оно и плохо, что малоприменимая, особенно если заказчик сам не знает что хочет. а при наличии тз-можно по его пунктам предьявить результат. и если заказчик чего то не написал, то доработки уже з отдельные деньги и в новые сроки
Для этого исполнитель может при получении вводных все расписать и согласовать, а договор потом делать на основе уже этой документации
PB
Просто возможна другая крайность - расписываешь все по пунктам, а потом ищешь 100500 лет исполнителя, которому норм работать с теми же технологиями, что и тебе, таким же образом, каким ты расписал и так далее
PB
Так для простых вещей можно. Простых с архитектурной точки зрения.
"Разработать и изготовить прототип усилителя с такой-то АЧХ, такими-то характеристиками по входу/выходу и такими-то по питанию".
"Разработать и изготовить прототип усилителя с такой-то АЧХ, такими-то характеристиками по входу/выходу и такими-то по питанию".
PB
Ну или хз, драйвер какой-нибудь, если речь о софте
KA
Малоприменимая мантра в реальности.
Как раз требование исчерпывающего ТЗ по пунктам - любимая фишка джуниоров. И на формирование полного и исчерпывающего ТЗ на простые задачи времени может уйти больше чем на ее решение.
Кроме того, утрясание вопросов со смежниками как правило лежит на плечах исполнителя .
Как раз требование исчерпывающего ТЗ по пунктам - любимая фишка джуниоров. И на формирование полного и исчерпывающего ТЗ на простые задачи времени может уйти больше чем на ее решение.
Кроме того, утрясание вопросов со смежниками как правило лежит на плечах исполнителя .
Не считаю себя джуном, но без ТЗ стараюсь не работать. Да, действительно, для небольших не очень ответственных проектов я многие решения принимаю сам, особенно если выяснение деталей в долбанной почтовой переписке. Но для крупных ответственных проектов без ТЗ - пиши - пропало/потрачено) хотя бы потому что заказчик сам не понимает что происходит и надеется на халяву - я проходил эту историю уже десятки раз
KA
Petr Belyaev
Просто возможна другая крайность - расписываешь все по пунктам, а потом ищешь 100500 лет исполнителя, которому норм работать с теми же технологиями, что и тебе, таким же образом, каким ты расписал и так далее
Обычно под подробное ТЗ намного быстрее находятся исполнители
В
Не считаю себя джуном, но без ТЗ стараюсь не работать. Да, действительно, для небольших не очень ответственных проектов я многие решения принимаю сам, особенно если выяснение деталей в долбанной почтовой переписке. Но для крупных ответственных проектов без ТЗ - пиши - пропало/потрачено) хотя бы потому что заказчик сам не понимает что происходит и надеется на халяву - я проходил эту историю уже десятки раз
вот вот, я с технологами имею дело в АСУ ТП, а они часто дуб дубом но амбиций и гонору выше крыши. напишут отписку мол это хотим а потом орут что программа говно и они не это хотели.и только после того как что то сломается, и им ткнут в нос ихную же писульку начинают спинным мозгом осозновать, что ТЗ всё таки писать надо полностью и осмысливать то что хотят получить.
PB
Обычно под подробное ТЗ намного быстрее находятся исполнители
Согласен. Мой посыл был, скорее, в том, что в ТЗ следует специфицировать интерфейсы: что на входе и что на выходе. А вот продумывать за исполнителя внутреннее поведение уже может быть не настолько полезно. От того, что внутри, требуется ясность, прозрачность и документация )
A
Не считаю себя джуном, но без ТЗ стараюсь не работать. Да, действительно, для небольших не очень ответственных проектов я многие решения принимаю сам, особенно если выяснение деталей в долбанной почтовой переписке. Но для крупных ответственных проектов без ТЗ - пиши - пропало/потрачено) хотя бы потому что заказчик сам не понимает что происходит и надеется на халяву - я проходил эту историю уже десятки раз
Для крупных и ответственных проектов существуют системы ведения проектов и методики, которые позволяют найти узкие места и скоординировать желания (заказчиков) и возможности (разработчиков разных сфер).
Это намного эффективнее, чем NNN страниц технического текста перелопачивать заново.
Это намного эффективнее, чем NNN страниц технического текста перелопачивать заново.
AK
Витька Корнеев
вот вот, я с технологами имею дело в АСУ ТП, а они часто дуб дубом но амбиций и гонору выше крыши. напишут отписку мол это хотим а потом орут что программа говно и они не это хотели.и только после того как что то сломается, и им ткнут в нос ихную же писульку начинают спинным мозгом осозновать, что ТЗ всё таки писать надо полностью и осмысливать то что хотят получить.
это потому что у них нет опыта работы в смежных областях
В
Для крупных и ответственных проектов существуют системы ведения проектов и методики, которые позволяют найти узкие места и скоординировать желания (заказчиков) и возможности (разработчиков разных сфер).
Это намного эффективнее, чем NNN страниц технического текста перелопачивать заново.
Это намного эффективнее, чем NNN страниц технического текста перелопачивать заново.
😂если бы
A
Витька Корнеев
😂если бы
Не получилось? )