Вирішуючи одне завдання, ми породжуємо інші проблеми

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

Як це сталося? Гаразд, припустимо, ви знаєте одного хлопця, і його звуть Джо.

Джо – надзвичайно крутий фахівець у своїй галузі, і, швидше за все, у нього навіть є сертифікат із написом: “Видано Джо Всевишньому”. Джо працює в компанії, де його люблять і цінують. Хоча в цьому немає необхідності, досить, щоб він був містером компетентності, і все.

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

Джо швидко виконав завдання, його перевірили та надіслали клієнту з позначкою “готовий та перевірений”. Але проходить деякий час, і клієнт приносить вам ще кілька завдань – проблем, пов’язаних із тим, який ви вирішили раніше з коментарем: «Ваше рішення – це зовсім не рішення, це якийсь вірус, який потрапляє в код проекту знищує його зсередини ”

Клієнт злий, Джо в депресії, компанія збентежена.

Хто винен? Що сталося і що робити?

Є одна правда – ми всі живемо у світі не чітко визначених завдань та обмежених ресурсів. Коли щось вам зрозуміло, це не означає, що це зрозуміло іншим. Ресурси: час, гроші – обмежені. Як правило, ті, у кого багато грошей, обмежені в часі, ті, у кого багато часу, обмежені в грошах.

Питання про завдання

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

Деякі коментарі до завдання можуть змінити саме завдання.

У завданні відсутній опис, завдання передано під час дзвінка. Не покладайтесь на свою пам’ять, вона не статична.

У завданні відсутня інформація про тестування (це особливо важливо для існуючих проектів, ви повинні мати документацію).

Опис не містить чітких інструкцій, умов, вхідних даних.

В описі відсутні ідентифікатори даних, такі як URL, ID / SKU, будь-який інший ідентифікатор, який би посилався на об’єкт або проблему.

Проблеми проекту / команди

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

Стиль мислення, досвід роботи з чиїмось кодом. Можливість швидко виявити джерело проблеми та саму проблему.

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

Але не все так погано, якщо

Проблеми вирішуються на етапі тестування.

Проблеми швидко вирішуються.

Проблеми, які виникають, аналізуються, і створюються документи з докладним описом взаємозв’язку між помилками та завданнями, які варто розглянути.

Спочатку ця публікація була опублікована за адресою https://www.linkedin.com/pulse/when-solving-one-task-we-give-rise-other-problems-sergey-vlasov/.

Sergey Vlasov люб’язно дозволив нам перекласти і опублікувати цю статтю.