Когда можно пожертвовать «аккуратностью» дизайна, чтобы завершить проект?

Когда вы работаете над продуктом, который должен быть сделан в ближайшее время и работать хорошо, когда можно пожертвовать ремонтопригодностью и «аккуратностью» дизайна, чтобы быстро выполнить работу и выйти за дверь? И в какой степени это нормально, особенно когда методы, используемые, чтобы сделать его "аккуратным", являются новыми для меня?

Помните, что вы работаете, чтобы поддерживать бизнес. В некотором смысле, ваше программное обеспечение влияет на итоговые показатели бизнеса. Вам необходимо найти баланс между технически совершенным решением, временем выхода вашего продукта на рынок и тем, какую выгоду от этого получит бизнес.

По моему опыту, разработчики часто зацикливаются на заботах о техническом совершенстве. Но есть очень веские причины жертвовать такими качественными характеристиками, как ремонтопригодность или производительность, чтобы быстрее вывести продукт на рынок. Это зависит от бизнеса и продукта. Но «всегда стремиться к идеальному дизайну» - это слишком упрощенный подход.

В конце концов, единственное, что имеет значение, это ценность для бизнеса. Выясните, как максимизировать его в краткосрочной и долгосрочной перспективе, и стремитесь к этой цели.

Термин «технический долг» очень удобен для информирования таких деловых решений. Любая работа, которую вы не выполняете сейчас, вызовет некоторое количество работы позже. Как и в случае с финансами, брать на себя долги рискованно, но, возможно, стоит воспользоваться, если вы сможете вернуть долг позже.

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

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

Когда это принято и последствия понятны владельцу / клиенту / пользователю.

Сантехник должен вывозить мусор на ремонт. В то же время я хочу использовать раковину, но он должен будет выставить мне счет за время и материалы, чтобы положить во временные трубы, используя ленту, которая может сломаться. Это также приведет к задержке возврата отходов в ремонтную мастерскую. Если я принимаю дополнительный биллинг с пониманием, что я рискую засорить. Это займет целый день, чтобы восстановить утилизацию и еще более долгую задержку, прежде чем он сможет ее вернуть, это приемлемо.

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

Многие люди быстро сдаются, когда узнают что-то новое, и делают это так, как всегда. Если это шаблон, пострадает не только ваш код, но ваши собственные навыки программиста останутся ограниченными.

Тем не менее, в конце концов, единственным успешным программным обеспечением является тот, который поставляется.

После того, как мягкий срок проходит. И даже тогда это очень низкая степень «ОК». После того, как жесткий крайний срок проходит, это, конечно, спорный вопрос. Потому что такова природа жестких сроков.

Кроме того, это влечет за собой технический долг. За каждый час / день, проведенный вами в менталитете «добро пожаловать», это будет стоить вам примерно вдвое больше времени, когда вы в следующий раз коснетесь этого проекта. Если вам нужно, то лучше спешить, отправить, а затем немедленно приступить к исправлению всей вашей утиной ленты. Возвращение к взломанному проекту лет спустя - кошмар. Если вы никогда не будете прикасаться к нему никогда, так тому и быть, никто не будет заботиться. Но единственный раз, когда я навсегда покинул проект, это когда я сменил работу.

Помните, однако, что выбор времени - это работа менеджера проекта. Если вы торопитесь уложиться в срок, это вина премьер-министра. Сделай это правильно, сделай это один раз, и делай это спокойно и правильно. Жизнь слишком коротка для чего-либо еще.

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

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

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

С учетом вышесказанного, не думайте, что если крайний срок для премьер-министра не будет достигнут, мир закончится и проект потерпит неудачу. Обычно это не то, что черное и белое, и большую часть времени крайний срок PM мягкий, и есть место для корректировки.

Почти каждый крайний срок, когда я был в расписании вечера, был в основном искусственным. Они будут защищать его изо всех сил и делать вид, что иначе, потому что, если премьер-министр отодвигает крайний срок, тогда премьер-министр выглядит плохо!

То, что премьер-министр выглядит плохо, не означает, что проект провалился. Если вы понимаете это, вы будете удивлены, насколько вы можете заставить PM согнуться.

Цитировать клиента за аккуратный дизайн. Если эта цитата неприемлема для них, то разберитесь, сколько будет стоить каждый компонент (обычно это стоимость == время разработки). Пусть они снимают предметы "а ля карт", если они захотят. Многие будут прыгать, экономя время на такие «бесполезные» вещи, как тестирование и дизайн. Объясните риски этого подхода, но если они принимают риск, действуйте в соответствии с указаниями. Если у меня будет достаточно денег только для машины, то я собираюсь купить машину, даже если знаю, что она сломается через 8 месяцев. Ваш клиент обязан взвесить эти риски и принять последствия.

Единственное, что вы не хотите делать, - это сказать клиенту, что он думает, что у него есть красиво разработанное программное обеспечение, когда он только заплатил (и получил) непроверенный кусок мусора. Если что-то пойдет не так (что, скорее всего, произойдет), в первом сценарии они будут выглядеть плохо, а во втором - плохо.

Это никогда не бывает хорошо, но иногда приходится идти на компромисс ради завершения проекта. Печальная реальность заключается в том, что большинство бизнесменов абсолютно невежественны и более чем готовы пожертвовать ремонтопригодностью ради чего-то прямо сейчас. Хитрость заключается в том, чтобы знать, как достичь баланса; возможно, проект не будет таким аккуратным, как мог бы, но если это не свинарник, это достойный компромисс.

Это полностью зависит от вопроса: «Вы или кто-либо еще, возможно, захотите изменить его позже?» Если да, вы должны попытаться иметь «аккуратный» дизайн, в противном случае вы рискуете выбросить все и начать заново через 6 месяцев.

Конечно, вы можете зайти слишком аккуратно, но, как правило, немного аккуратности спасет вашу работу позже.