Если мы имеем внутренний проект, что важнее сделать в максимально короткие сроки как просит высшее руководство, со всеми вытекающими и получить всем звезды, но при этом техническое качество будет плохим (потом подразумевается рук-во не будет так пушать для запуска и можно отрефакторить)
или же пробить сроки больше и сделать сразу хорошее техническое качество?
Здравствуйте, peer, Вы писали:
P>Если мы имеем внутренний проект, что важнее сделать в максимально короткие сроки как просит высшее руководство, со всеми вытекающими P>или же пробить сроки больше и сделать сразу хорошее техническое качество?
Я думаю как руководство просит, так и надо делать. Если просит быстро, тогда делать быстро. Если просит качественно, тогда делать качественно.
Здравствуйте, peer, Вы писали:
P>Если мы имеем внутренний проект, что важнее сделать в максимально короткие сроки как просит высшее руководство, со всеми вытекающими и получить всем звезды, но при этом техническое качество будет плохим (потом подразумевается рук-во не будет так пушать для запуска и можно отрефакторить) P>или же пробить сроки больше и сделать сразу хорошее техническое качество?
Это ж от многих обстоятельств зависит, нам неведомых.
Может, руководству надо хоть что-то показать, чтобы хоть как-то работало, но вчера. Иначе денех не будет и контрактов не будет и ничего вообще не будет.
А может руководство думает, что програаммист — птица гордая, без пинка не летит. И на всяк. случай продавливает нереальные сроки, чтобы получить результат хоть к последним реальным. А в какчество ваше вообще не верит.
Эти ж разные ситуции, а ты просишь однозначного какого-то ответа.
Здравствуйте, peer, Вы писали:
P>Если мы имеем внутренний проект, что важнее сделать в максимально короткие сроки как просит высшее руководство, со всеми вытекающими и получить всем звезды, но при этом техническое качество будет плохим (потом подразумевается рук-во не будет так пушать для запуска и можно отрефакторить)
Стейкхолдерам всегда надо быстрее, но на деле что-то можно даже не делать т.к. в реальности это им не нужно. Попробуй понять, что нужно сделать, а что нет или почти не нужно, и выкатить только необходимое с нормальной архитектурой.
Рефакторить через какое-то время вряд ли будешь т.к. это не создаёт ценность и будут вопросы зачем переделывать то, что и так работает. P>или же пробить сроки больше и сделать сразу хорошее техническое качество?
Если заказчик готов на такое пойти, то почему нет? P>Тут дискуссия развернулась.
Отталкиваться стоит от своих целей. Если ты планируешь работать в компании 2+ лет, то, вероятнее всего, код написанный сейчас придётся модифицировать тебе же через 2 года. Хочешь ли ты ковырять такой код через 2 года, спроси себя сам. Даже если ты будешь менеджером, то ковырять будут вместо тебя, но твой бонус будет зависеть от успехов команды программистов. Если будешь менять работу, то не всё ли равно что будет через 2 года с проектом? Решаешь текущие проблемы, получаешь бонусы, а через 2-3 года меняешь компанию. Своих стратегических целей ты достигаешь, а стейкхолдеры... ну они сами должны понимать какие у них стратегические цели .
Ясно-дело, что тут проблема проектного треугольника. Но необязательно делать с плохим качеством. Можно сделать и с хорошим.
Надо узнать, что точно хочет руководство. Например, работающий прототип к какой-то выставке или же что-то работающее для показа инвесторам.
Далее, узнаем средне- и долгосрочные планы. Например, вероятность, что проект выстрелит и в-принципе будет дальнейшее развитие проекта, мала. Или же в случае успешного показа MVP дадут 5 лет на доработку до конца.
Потом, узнаем, какие компоненты/аспекты системы важны в первую очередь. Например, крайне важно произвести впечатление интерфейсом. Или же это около-научное, где в первую очередь важны точные расчеты, или же важна скорость.
Основываясь на этих вводных прорабатываем стратегию, просчитываем риски, обозначаем ограничения системы и выдаем несколько вариантов руководству с описанием всех плюсов, минусов, рисков и ограничений + стратегия развития в дальнейшем.
Ну если вкратце суммировать: сделать быстро != сделать плохо.
Здравствуйте, peer, Вы писали:
P>Тут дискуссия развернулась.
P>Если мы имеем внутренний проект, что важнее сделать в максимально короткие сроки как просит высшее руководство, со всеми вытекающими и получить всем звезды, но при этом техническое качество будет плохим (потом подразумевается рук-во не будет так пушать для запуска и можно отрефакторить) P>или же пробить сроки больше и сделать сразу хорошее техническое качество?
Нет такой дихотомии.
Если нет понимания задачи, и решите делать хорошо и долго, то будете делать долго но сделаете все равно плохо.
Качество достигается либо уже имеющейся экспертизой, либо несколькими итерациями.
Если есть понимание задачи, то разобьете задачу на этапы и быстро сделаете минимальную версию с необходимыми функциями,
а потом при необходимости будете доделывать расширения.
.
