Це ознаки поганого розробника? [зачинено]

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

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

Чи є ознаки, на які я повинен пильнувати, де я повинен змінити своє ставлення? Чи завжди клієнт має рацію, чи я іноді виправдовуюся розчаруватися?

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

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

Бути вірним оригінальній специфікації не реально. Також нереально постійно змінювати вимоги.

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

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

Бувають випадки, коли це Клієнт. Але і в цьому ваша проблема

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

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

Вид дзен-розуму: не судіть про це, просто подивіться, як є.

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

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

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

Зміна вимог - важкий факт життя; але гниль коду цим не викликана.

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

Так, це ваша вина, а не ваш користувач.

Справжнє рішення? часто перевіряйте весь код. Звичайно, найкращий спосіб - автоматичні тести з хорошим покриттям.

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

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

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

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

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

Під час взаємодії з клієнтом ви не програмуєте; ви навчаєтесь і викладаєте.

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

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

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

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

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

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

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

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

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

У цитаті Емерсона: "Нерозумна послідовність - це гобгоблін маленьких розумів ...", найчастіше пропущене слово - нерозумне . Послідовність не підлягає обговоренню в певних умовах, але все це часто підміняє критичне мислення та аналіз.

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

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