Коли це в порядку пожертвувати «акуратністю» дизайну, щоб виконати проект?

Коли ви працюєте над продуктом, який потрібно зробити незабаром, і добре працювати, коли це добре, щоб пожертвувати ремонтом і «акуратністю» дизайну, щоб швидко зробити справу і вийти з дверей? І наскільки це нормально, особливо коли методи, які використовуються для того, щоб зробити його "акуратним", для мене є новими?

Пам'ятайте, що ви працевлаштовані, щоб підтримувати бізнес. Певним чином ваше програмне забезпечення впливає на суть бізнесу. Вам потрібно досягти балансу між технічно досконалим рішенням та часом виходу на ринок свого товару та тим, скільки користі буде отримувати бізнес від цього.

На мій досвід, розробники часто зависають від занепокоєння щодо технічної досконалості. Але є дуже вагомі причини пожертвувати такими атрибутами якості, як ремонтопридатність або продуктивність, щоб швидше вийти з продукту. Це залежить від бізнесу та товару. Але "завжди прагнути до ідеального дизайну" є надто спрощеним підходом.

Зрештою, важливе значення має лише цінність для бізнесу. З’ясуйте, як максимально досягти цього в коротко- та довгостроковій перспективі та прагнути до досягнення цієї мети.

Термін "технічна заборгованість" дуже зручний, щоб допомогти інформувати подібні бізнес-рішення. Будь-яка робота, яку ви зараз не робите, пізніше призведе до певної роботи. Як і у випадку з фінансами, взяти на себе борги є ризикованим, але, можливо, варто скористатися, якщо ви зможете повернути борг пізніше.

Сказавши це, технічна заборгованість не є співвідношенням 1: 1 під час окупності. Виправлення помилок дорожче виправити після випуску, і вплив на майбутню продуктивність при розробці з безладної спадкової системи може бути кричущим. Ви можете дивитись на те, щоб витратити вдвічі більше часу на виправлення помилок, а може, в 1000 разів більше людей-годин і ресурсів.

Ваша робота в цьому рішенні - зрозуміти наслідки конкретних деталей розрізування кутів, які ви розглядаєте, а потім донести ці наслідки до людей, які приймають бізнес-рішення. Цей конкретний навик оцінювання може зайняти багато досліджень і роботи з вашого боку, щоб зараз добре розвиватися, але це буде неоціненно протягом вашої кар’єри.

Коли він прийнятий і наслідки розуміються власником / клієнтом / користувачем.

Сантехнік повинен вивезти сміття на ремонт. Я хочу використовувати мийку в середній час, але йому доведеться виставити мені рахунок за час і матеріали, щоб покласти у тимчасові труби за допомогою стрічки, яка може зламатися. Це також затримає повернення утилізації до ремонтної майстерні. Якщо я приймаю додатковий рахунок, розуміючи, що ризикую засмітити. На відновлення вивезення знадобиться день довше, і ще довша затримка, перш ніж він зможе повернути його назад, це прийнятно.

Ви можете бути вчасно та з бюджетом, але жертвувати / ризикувати ще більшим зарядом у довгостроковій перспективі. Це може бути важко змусити людей нетехнічних зрозуміти, але саме для цього потрібен персонал з продажу.

Дуже багато людей швидко відмовляються, коли дізнаються щось нове, і просто роблять так, як завжди робили. Якщо це зразок, не тільки ваш код постраждає, але і ваші власні навички програміста залишаться обмеженими.

І все-таки на кінець дня єдиним успішним програмним забезпеченням є те, що постачається.

Після того, як пройде м'який термін, І навіть тоді це дуже низький ступінь "ОК". Після того, як важкий термін пройде, це, звичайно, суперечка. Тому що така природа жорстких термінів.

Крім того, це несе технічну заборгованість. За кожну годину / день, коли ви проводите різання куточків у ментальному режимі, це обійдеться вам приблизно вдвічі більше часу, коли вам доведеться торкнутися цього проекту. Якщо вам потрібно, то найкраще поспішити, відправити, а потім негайно почати фіксувати всю качку. Повернутися до проекту, котрий триває довгі роки, - це кошмар. Якщо ви його більше ніколи не торкаєтесь, так і буде, нікому не буде байдуже. Але єдиний раз, коли я назавжди покинув проект, - це коли я перейшов на роботу.

Пам'ятайте, хоча, приурочення цих речей - це робота керівника проекту. Якщо вам поспішають достроковий термін, винна Прем'єр-міністр. Зроби це правильно, зроби це один раз, і роби це спокійно і правильно. Життя занадто коротке для чого-небудь іншого.

Усі інші відповіді, розміщені тут, хороші. Хотілося б додати, що як розробник проекту, ви - управитель (захисник) дизайну.

Якщо ви не відстоюєте належне технічне рішення, я вам нікого більше не обіцяю. Ви завжди повинні стверджувати, що ви робите справи правильному шляху до свого начальника, а прем'єр-міністр повинен завжди стверджувати на користь строку.

Сподіваємось, якщо ви знаходитесь у розумній організації, буде досягнутий компроміс, який допоможе дотриматись термінів, а також не відхилятися занадто далеко від дизайну.

Зважаючи на це, не варто вважати, що якщо не буде досягнуто граничного терміну, прем'єр-міністр закінчиться, і проект провалиться. Зазвичай це не так чорно-білі кольори, і більшість часу термін дії прем'єр-міністра є м'яким і має місце для коригування.

Майже кожен термін, у який я коли-небудь був за графіком PM, був здебільшого штучним. Вони захищатимуть це зубом і нігтями, і прикидаються інакше, тому що, якщо прем'єр-міністр відсуває термін, то прем'єр-міністр дивиться на непридатність!

Просто те, що прем'єр-міністр виглядає погано, не означає, що проект провалився. Якщо ви це зрозумієте, ви здивуєтеся, скільки ви можете змусити прем'єр-міністра прогнутися.

Пропонуйте клієнту акуратний дизайн. Якщо ця цитата для них неприйнятна, перейдіть до розбиття того, що буде коштувати кожен компонент (зазвичай це вартість == час розробки). Нехай вони знімуть речі "а-ля-карт", якщо вони захочуть. Багато людей скачуть на час гоління на "непотрібні" речі, такі як тестування та дизайн. Поясніть ризики такого підходу, але якщо вони приймають ризик, то продовжуйте діяти за вказівкою. Якщо у мене достатньо грошей на автомобіль clunker, я збираюся придбати автомобіль clunker, навіть якщо я знаю, що він, ймовірно, вийде з ладу через 8 місяців. Ваш клієнт несе відповідальність за зважування цих ризиків та прийняття наслідків.

Єдине, чого ви не хочете робити, - це сказати, нехай клієнт подумає, що у них є гарний дизайн програмного забезпечення, коли він лише заплатив (і отримав) неперевірений шматок сміття. Якщо щось піде не так (що, швидше за все, буде), у першому сценарії вони будуть виглядати погано, а в другому - ви будете погано виглядати.

Це ніколи не гаразд, але іноді доводиться йти на компроміс заради закінчення проекту. Сумна реальність полягає в тому, що більшість бізнесменів абсолютно неосвічені і більше ніж готові пізніше пожертвувати ремонтом за щось. Хитрість полягає в тому, як знати баланс; можливо проект не буде настільки акуратним, як міг би бути, але поки це не порося, це гідний компроміс.

Це повністю залежить від питання "Ви чи хтось інший, можливо, захочете його змінити пізніше?" Якщо так, то вам слід спробувати мати "акуратний" дизайн, інакше ви ризикуєте все викинути і почати знову через 6 місяців.

Звичайно, ви можете зайняти акуратність занадто далеко, але, як правило, трохи акуратності позбавить вас працювати згодом.