Comments 6
Правильная постановка задачи - забота менеджмента. Правильно задавать вопрос, если не понял - задача разработчика.
В целом, конечно, согласен. Но, камон. Если неопытный проджект или, тем более, клиент дал задачу "сделай кнопку", а специалист ничего не сказал\спросил в ответ - то тут и проблема в разработчике. Ну и далее вопросы, а разработчики имеют право сказать "нет"? А могут поспорить с проджектом? А могут клиенту объяснять, что такая постановка задач жрет время и бджет клиента, и давайте выведем более эффективную формулу взаимодействия. Или лучше проджект\экаунт пойдет и все выяснит и вернется с адекватной задачей...
Хм... Значит, когда разрабы решили писать все рабочие файлы (размером в 100 - 400 Мб) в базу 1С, - виноват заказчик, который не предупредил, что так делать не надо.
И с кнопкой история знакомая. Кнопку сделать сложно, а оператору руками ковыряться минут 15 - нет.
А разработчики они совсем "ротом пользоваться не умеют"? А задачу, видимо, приносит сова в свитке и совершенно нет никакой возможности дать обратную связь.
К тебе приходит фича-реквест, ты должен рассказать "заказчику", какие сложности могут быть в реализации и предложить варианты. Может быть после твоего рассказа задача вообще отвалится, потому что это нерентабельно или можно изменить постановку таким образом, чтобы реализация не потребовала изменения всей архитектуры.
P.S. у меня в команде были и противоположные случаи, когда "заказчик" честно думал, что там надо всю архитектуру переписывать и задача на неделю, а мы ему это делали за 15 минут (потому что реально все было готово) и он уходил заливаясь слезами радости :-)
Это палка о двух концах — безусловно, проблемы бывают и со стороны разработки. Где-то не хватает инициативности, где-то не озвучены риски, а где-то и правда можно было бы просто задать пару вопросов
Но конкретно в этой статье я сознательно фокусировался на управленческой стороне: как формулируются задачи, с каким контекстом они приходят, и почему иногда сами вводные мешают нормальной работе. Про ответственность разработчиков — абсолютно согласен
Я бы сказал, что такое часто бывает в компаниях, где "всё это айти" не профильное. Ну, типа, вот мы компания, которая торгует помидорами и решили внутри себя тоже открыть Айти департамент, но при этом четкого понимания зачем и что он делает в целом по компании нет. Кроме того, в таких компаниях, айти департамент не является тем, что приносит деньги, поэтому и постановка из серии "я вам плачу деньги, и вы двигаете кнопки".
Там, где прогеры делают основной продукт, который генерит деньги вопрос ставится следующим образом: "мы хотим изменить то, что и так работает и приносит деньги с риском факапа (который всегда не нулевой)".
С одной стороны да, а с другой стороны, тут что-то наподобие старого-доброго "как правильно задавать вопросы". Если разработчик завален задачами, то он скорее возьмётся за те задачи, в которых ему всё понятно. Особенно большой шанс попасть на игнор, если этот разработчик этому заказчику уже неоднократно объяснял, что именно нужно описывать в постановке задачи, но заказчик продолжает писать задачи вида "сделайте хорошо".
“Разработчики тупят” — а может, просто задачи дурацкие?