Як підійти до слова "" це буде лише невелика програма "? Так правда?

Гаразд, я багато разів стикався з цим, але ось гірший сценарій трохи перебільшений.

Клієнт каже: "Ей, чи можете ви змусити нас цей маленький модуль зробити це невелике завдання?"
Я: «Звичайно, немає проблем».

Тож, виходячи з бюджетів та обмежень тощо, я пропускаю частину архітекторів і занурююсь прямо, і це не потіє.

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

Що ви робите, коли вас просять зробити щось маленьке? Ви не знаєте, чи буде він продовжувати зростати ... якщо клієнт буде продовжувати просити доповнення (і не вони).

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

Вони скажуть «так так» і підуть до когось іншого.

Бюджет, час та сприйняття так само важливі, як і архітектура самої програми.

Як слід до цього підходити?

Я думаю, що питання справді зводиться до "Коли у вас немає всієї інформації для остаточного результату того, що видається невеликою програмою, як уникнути (або пом'якшити) прийняття архітектурних та дизайнерських рішень на ранніх стадіях, це буде повністю невідповідні пізніше?

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

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

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

Переконайтесь, що вони розуміють три речі:

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

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

3. Щоб ви не намагалися швидко заробити. Справа НЕ потребує перепроектування.

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

Просто зробіть йому невеликий додаток і заплатите за нього.

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

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

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

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

Я не можу не відчути, що треба робити, - бути чесним із клієнтом та дати їм вибір: 1. Я можу це зробити швидко та (відносно) дешево. Це буде чудово - воно буде працювати - але майбутні вдосконалення будуть коштувати трохи більше 2. Я можу витратити більше часу на нього вперед, що обійдеться трохи більше і не додасть ніякої реальної користі для користувачів, АЛЕ це допоможе вам заощадити гроші, якщо вам потрібно буде додати нові функції.

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

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

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

Це один спосіб подивитися на це, а не один ... проект LONGGGGGG.

як ти уникаєш (або пом'якшуєш) прийняття архітектурних та дизайнерських рішень на ранніх стадіях, які згодом будуть абсолютно невідповідними?

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

У вашому запитанні було зазначено, що у нього були бізнес-процеси, але я не впевнений, чи це хороші процеси. Ось кілька покажчиків:

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

Ваш зарослий продукт

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

Натомість я б уклав контракт на зміни, про які запитав користувач. Додайте додатковий час для кожної функції, використовуючи початковий час для роботи над функцією, та додатковий час для покращення загальної архітектури, одне невелике вдосконалення за один раз. Мета полягає не в тому, щоб повністю «зафіксувати» архітектуру одним контрактом, а замість того, щоб повільно чіпати її з часом.

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