Як боротися з програмами програмування, які провалюються?

Не рідкість проекти провалюються.

Як програміст, як ви маєте справу з невдалими проектами?

Деякі визначення відмови:

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

Або, можливо, у вас є власні визначення невдач.

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

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

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

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

За мою єдину справжню невдачу за останні 30 років, проект висувався вимогами буквально років, коли ми приїхали. Ми вирішили вимоги. Один прийшов від управління, а сотні - від кінцевих користувачів. Ми написали код, багато коду, деякі - блискучі. Було тестування та тестування на прийняття, зміни та аргументи, запити на зміну та неоплачувана робота та оплачувана робота та підключення в останні хвилини, сюрреалістичний гумор та ескалації до ВП та все це. Врешті-решт все просто натрапило. Причиною відмови було те, що єдина вимога управління була неприйнятною для кінцевих користувачів. І скільки б речей вони не проходили, вони не змогли обійти цю проблему і ніколи не приймуть систему. Але управління не було б іншого способу. Так це було, і хоча ми отримали багато грошей, зрештою,

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

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

Існує чудова книга на цю тему під назвою Марш смерті: http://www.amazon.com/Death-March-2nd-Edward-Yourdon/dp/013143635X

Я настійно пропоную вам прочитати його. Ви можете розпізнати свої проекти в багатьох описах.

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

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