Бізнес намагається приймати технічні рішення

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

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

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

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

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

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

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

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

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