Ми всі були там:
Моє запитання: який найпродуктивніший спосіб програмісту впоратися з помилками, пов'язаними з розвитком, такими як ці?
Відповіді:
Ваш проект не вдався.
Розробка програмного забезпечення дуже схильна до збоїв у проекті, і залежно від ступеня серйозності, цим найкраще займається керівництво.
Багато проектів зазнали невдачі, і багато інших провалиться, тому робіть замітки! Дізнайтеся, чому ваш проект провалився, щоб ви не робили однакових помилок наступного разу. Ви дізнаєтесь набагато більше від своїх невдач, ніж від своїх успіхів.
Ваша команда відхилила те, на що ви витратили дні кодування.
Збережіть свою роботу (на потім). Є дві можливості: (а) це відстійно, і факт того, що кілька людей реагували однаково, є свідченням цього (б) Це справді геніальна робота, але далеко попереду того, що люди звикли чи можуть зрозуміти. Люди взагалі не люблять те, чого вони не розуміють. Можливо, краще показати це, коли настане час АБО в іншому місці з іншою "Культурою"
Ніхто не слухає ваших ідей у вашій компанії.
Ймовірно, це погана ідея, АБО культура не узгоджується з вашим мисленням. Або переїжджайте на місце, яке підтримує вашу культуру, або критично оцінюйте свою ідею ще раз (об'єктивно без власних упереджень) -> чи справді моя така ідея гарна? <- Вбий своє его
Шаблон дизайну, який ви запровадили із силою у вашій команді, створив безлад.
Якщо чесно, ви постаралися, але не вийшло, як ви це планували. Можливо, краще почати заново або вчитися на помилках, зроблених у дизайні як команда, і рухатися вперед.
Вони не невдачі - це досвід
Ви дізнаєтесь і зростаєте зі свого досвіду, розмірковуючи про те, як вони змусили вас почуватись, і якщо ви хочете більше цього почуття.
Якщо це поганий досвід (як той список, який ви запропонували), то супутнє погане самопочуття - це, мабуть, те, чого ви хочете уникати (якщо вважати, що ви не настільки товсті, що вам не хвилювало вплив своїх дій).
Взагалі, не варто занадто часто брати участь у порівнянні себе з іншими, у них виникають стільки ж проблем, як і все це .
Ви щось будуєте.
Для мене (я не думаю, що це підходить для всіх), побудувати щось (комікси, малюнки, маленькі ігри, що-небудь) - це як побудувати трохи впевненості, щоб повернутися до боротьби з невдачею. Це також може бути хорошим способом висловити свій гнів чи гіркоту чи будь-які почуття відносно невдачі, але "конструктивним" способом.
Це для мене все одно працює.
Ну, ви запитали :) Один за одним:
* Your project failed.
Це навряд чи нове. Ми всі провалилися приватно, і всі ми провалилися з огляду на наших ровесників. Кожен, хто пройшов початкову та середню освіту, пережив це.
Якщо я не можу помилитися і очікую стабільної зайнятості, вам слід розглянути можливість надсилання доповідної записки в службову службу, щоб дати їм знати, що людям заборонятимуться в майбутньому.
Кілька відмов підряд означає, що у вас є або необгрунтовані вимоги та технічні характеристики, або ви не вчитеся на своїх помилках. Будь-який сценарій вимагає негайних дій.
Можливо, що багато людей підписують щось на те, щоб лише працевлаштуватись, а потім відпрацьовувати певний спосіб здійснення вимог.
* What you have spent days coding was rejected by your team.
Це трапляється. Як зазначали інші, збережіть це. Зробити це знову. Ось чому ми називаємо це роботою. Я думаю, що в цьому випадку ви, мабуть, не дуже залучали команду до того, що робите.
Можливо також, що вимоги змінилися вчора, або годину тому. Це має бути винятком, а не нормою. Експертна оцінка настільки ж жорстока, як і корисна. Якщо ваш код постійно відхиляється як "неадекватний" (чи щось подібне), вам слід більше часу витрачати на вибір мізків та залучення інших. Я вважаю, що це питання є помилковим у більшості командних налаштувань, якщо тільки «команда» є лише описом.
* Nobody listens to your ideas in your company.
Знову ж таки, для цього потрібен контекст. Як давно ти там? Наскільки ваші колеги-хакери вірять у ваші здібності? Чи вважали ви, що ідеї, які призводять до більшої роботи для багатьох людей, можуть запропонувати будь-яку причину відхилити її? Колись я щось відхиляв, оскільки він не був готовий до IPV6, але він використовував простий сокет домену на пристрої циклу (виключно). Людина, яка його потопила, просто не могла більше працювати.
Крім того, наскільки добре ви артикулюєте себе? Чи можете ви дружити і впливати на людей?
* The design pattern you introduced with force in your team created a mess.
Отже, чому слід уникати сили. Вміти говорити - не обов’язкова умова слухати. Інших коментарів немає.
О, хлопче, це багато, якщо ти справді мав на увазі все, що трапилося з тобою!
ПОПЕРЕДЖЕННЯ . У багатьох пунктах нижче ви можете відчути, що я критикую вас, і що я хочу зробити вас відповідальними за помилки, а не враховувати зовнішні фактори. Я не. Просто ви не вказуєте багато деталей, і я просто надаю контрольні списки дій, які слід здійснити для того, щоб все не пішло. Я знаю, що я робив багато помилок (всі це роблять), і нам стає краще, лише якщо ми вчимося на них. І щоб вчитися у них, нам потрібно почати сприймати їх як помилки в першу чергу і приймати відповідальність за те, що пішло не так з нашого боку. Чорт, прийміть відповідальність за те, що пішло не так у чужих частинах, ви також можете навчитися цьому.
Зараз ви не можете багато зробити, щоб пом'якшити це.
Однак ви можете зробити багато, щоб уникнути цього в майбутньому. Я б запропонував спробувати вдосконалити свої навички управління проектами та часом.
Одну з книг з найкращим співвідношенням ((дійсна порада) / сторінок), яку я прочитав на цю тему, хоча, можливо, і не найкращу, це Радік Управління радикальними проектами Роб Томсет .
Ви дійсно не вказуєте, що ваш проект провалився, але я б припустив поєднання того, що призвело до незбалансованості у звичайному трикутнику вартість / час / кваліфікація . Найважливіший фактор, на мій погляд, - керувати проектом та розробкою, завжди підтримуючи контакт як з вашими технічними суб'єктами (розробниками та тестерами), так і зі своїми зацікавленими сторонами. Занадто багато проектів не вдається, оскільки вони не слухають спонсорів або зацікавлених сторін і не підштовхують їх до участі в процесі.
Якщо вони не залучені, ви не можете знати, чого вони хочуть. Якщо ви не можете знати, чого вони хочуть, ви не можете його доставити. Якщо ви не доставите її, вони будуть незадоволені. Це невдача. Крім того, якщо ви не залучаєте своїх зацікавлених сторін, вони відключаються від реальності програмної інженерії, тобто вони не розуміють ваших проблем. Якщо вони часто контактують з вами, вони краще розуміють, з чим ви маєте справу. Вони зможуть зрозуміти, коли ти скажеш їм, що "маленька" функція [сміху] займе місяці. Вони можуть довіряти вашому плануванню краще, тому що допомогли побудувати його. Проект не може досягти успіху лише з "специфікаціями на початку, розробкою, тестуванням, доставкою в кінці". Це просто ніколи. Ви можете доставити те, що просили в специфікаціях,
Найголовніше - також зробити ретроспективу , і переконайтесь, що це не є его та не є грою на вину. Просто визначте проблеми.
Я був у цій ситуації. Знову ж таки, не так багато ви можете зробити, щоб пом'якшити це, крім:
Але знову можна зробити щось, щоб запобігти подібній ситуації:
Ну, тут є два варіанти, і ми розглянемо обидва:
Почнемо припускати, що вони погані (знову ж, саморефлексія над цим і прийняття вашої ідеї було просто очевидним може бути складно, я знаю. Що ви робите, щоб змінити це?
Ідеї - це лише ідеї. Якщо ви просто запропонуєте їх як ідеї, і вони будуть відкинуті, я не бачу, чому б ви почувались погано. Якщо ви поступаєте з ними, не повідомляючи про це нікого, а потім подаєте лише свої ідеї, і вони відхиляються, я, очевидно, відчуваю розчарування в той час. І ваші менеджери це роблять!
Припустимо, що ваші ідеї були хорошими:
Також я трохи здивований самим підходом. Ви повинні були на самому справі натиснути на шаблон проектування бути введені? Це здається дивним. Візерунок вже є, або вам потрібно переробляти частину свого рішення відповідно до зразка. Ви не штовхати його , як ви б прийняття рамок або технологій (наприклад , люди штовхнуло дуже важко мати XML всюди, і тепер , як люди починають штовхаючи , щоб мати можливість написати HTML5 на їх обкладинці продукту у великих яскравих буквах).
Чому вам довелося натискати? Чому був спротив? Можливо, це було виправдано.
Чи змогли ви надати приклади того, що саме ця модель допоможе суттєво покращити базу коду (наприклад, зіставивши її із прикладом Refactoring to Patterns ).
Повністю поза тематичне зауваження, але це те, що я вперше подумав, коли читав заголовок питання, коли думав, що це стосується збоїв у програмному забезпеченні ... У мене було програмне забезпечення, яке реалізувало клас BlackHole для управління дуже особливим видом винятків в одному з компоненти. Це може здатися (і справді є) очевидно дивним і брудним злом, але саме називання було настільки чудовим, що ми всі оцінили його за досить класний спосіб впоратися з невдачею! :)
По-перше, зрозуміло бути засмученим або розлюченим при зіткненні з невдачею. Якщо давати пораду комусь у такій ситуації, вони, швидше за все, не захочуть почути "Просто перейміть це та рухайтеся далі" або "Просто подумайте про це як про можливість навчання".
Насправді, я думаю, що може бути здоровим і продуктивним засмучуватись і випускати свої розлади, за умови, що ви це робите приватно або з другом. Люди мають різні способи зробити це, але я думаю, що один з найпродуктивніших способів - написати розгніваний підроблений лист (Важливо! Не надсилайте цього листа нікому ). Поясніть свої почуття, наприклад, чому ви відчуваєте, що все, що сталося, було невиправданим.
Переконайтеся, що ви висловили все, що відчуваєте, і після випромінення гніву просто знадобиться трохи часу, щоб заспокоїтися. Можливо, вам потрібно лише кілька хвилин, а може, і кілька годин.
У цей момент ви, сподіваємось, зможете по-об'єктивніше подумати над ситуацією. Якщо ви написали лист, то прочитайте його собі. Якщо ви комусь довірилися, то спробуйте згадати, що ви сказали. Якщо ви просто уявили собі кричати на когось, то просто подумки перегляньте це.
Я часто пишу лист, коли розлючуюся, а потім, коли я заспокоївся, буду працювати над уточненням листа, щоб більш чітко повідомити те, що спочатку намагався сказати, поки не переконаюся, що хтось, хто його читає, зрозуміє, що я почуття в той час.
Справа в тому, щоб об’єктивно спробувати визначити, які були ваші бали. Вони мали сенс? Можливо, їм потрібне уточнення або подальша деталізація. Вони є безпідставними? Якби ви об'єктивно ставили себе в чужі черевики, ви зрозуміли б моменти, які ви зробили? Чи погоджуєтесь ви з цими пунктами? Ви можете використовувати цю можливість, щоб оцінити себе. Що ти зробив добре? Які речі можна було зробити краще?
Чи можна щось зробити, щоб виправити ситуацію або принаймні покращити її? Знайдіть хвилину, щоб задуматися, чи реально є щось, що можна зробити, щоб виправити чи покращити ситуацію. Часто немає, але іноді є.
Якщо ви в чомусь винні, то це може бути настільки ж простим, як формальне вибачення перед кимось, чітко пояснюючи, що пішло не так, що ви зробили, чому ви це зробили, і що ви зробите, щоб виправити це чи не допустити цього майбутнє.
Далі, подумайте, що ви можете зробити, щоб покращити майбутнє. Що ви можете зробити, щоб те ж саме не повторилося? Вирішіть, що ви хочете досягти, і використовуйте те, що ви навчилися з кроку 3, щоб створити план для себе.
Якщо все інше не вдалося, спробуйте перезавантажити:
try
{
// ...
}
catch (OhNoes111Exception)
{
// reboot fixes everything!
System.Diagnostics.Process.Start("ShutDown", "/r");
}