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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: