(Translations) Запитайте себе "А що б зробив користувач?"

Переклад статті з книги 97 Things Every Programmer Should Know про те, як мислить юзер і як його краще зрозуміти. Більше стосується програмування, та думаю і тестерам може бути цікаво. Буду вдячний за будь-які зауваження щодо помилок чи неточностей. Також вдячний друзям за допомогу. Ну що ж, поїхали!

В оригіналі статтю можна прочитати тут.

Запитайте себе "А що б зробив користувач?"

Giles Colborne

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

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

Найкращий спосіб дізнатися, як думає користувач, -- це спостерігати за ним. Попросіть його виконати якесь завдання, використовуючи програмне забезпечення, схоже на те, що ви розробляєте. Переконайтесь, що завдання цілком реальне: "Знайти суму колонки чисел" -- нормально; "Підрахувати витрати за останній місяць" -- взагалі чудово. Уникайте занадто конкретизованих завдань, на зразок "Виберіть комірки таблиці і введіть формулу сумування під ними" -- занадто багато підказок в одному реченні. Дозвольте користувачу розповісти про його успіхи. Не перебивайте. Не намагайтесь допомогти. Постійно запитуйте себе "Чому він робить саме так?".

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

Ви побачите, як користувачі потрапляють у глухий кут. Коли ви потрапляєте в таку ситуацію, ви оглядаєтесь навколо. Користувач же, коли опиняється в тупику, навпаки, зосереджується на місці виникнення проблеми. Йому стає важче побачити рішення деінде на екрані. Ось чому тексти допомоги є поганим рішенням проблеми неякісно розробленого інтерфейсу. Якщо необхідно подати інструкції або текст допомоги, обов’язково розташуйте їх поряд з проблемними місцями. Через вузьке поле уваги користувача спливаючі підказки ефективніші, ніж меню допомоги.

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

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

(Translations) Beauty Is in Simplicity - Jørn Ølmheim

Оригінал статті можна прочитати тут.

Beauty Is in Simplicity - Jørn Ølmheim

Краса у простоті

Jørn Ølmheim

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

У характері, в манерах, в стилі, у всьому цьому найпрекрасніше - простота.

Усього в одному реченні описані всі цінності, до яких ми повинні прагнути як розробники програмного забезпечення.

Ось кілька властивостей, які ми прагнемо надати коду:

• Легкість читання
• Легкість підтримки
• Швидкість розробки
• Невловиме поняття краси

Платон каже, що всі ці якості можна досягнути через простоту.

Що таке гарний код? Це дуже суб’єктивне питання. Сприйняття краси, як і будь-чого іншого, залежить від нас самих. Люди з художньою освітою сприймають красу не так, як люди з технічною освітою (чи, принаймні, мають інший підхід до краси). Знавці мистецтв при оцінці краси програм порівнюють їх з творами мистецтва, натомість науковці згадують симетрію і золотий переріз та намагаються звести все до формул. Наскільки я знаю, більшість аргументів обох сторін ґрунтується на простоті.

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

Ви вже повернулись? Чудово. На чому ми зупинилися? Ага... Я помітив, що код, який я вважаю красивим, має декілька спільних ознак. Головною з них є простота. Я вважаю, що незалежно від того, наскільки складна програма чи система в цілому, окремі частини повинні бути простими: прості об’єкти з простими обов’язками, які містять так само прості, сфокусовані методи з описовими назвами. Дехто вважає, що короткі методи на 5-10 рядків коду -- це занадто, і цього важко досягнути на деяких мовах, але я вважаю, що все одно така стислість є бажаною метою.

Отже висновок такий: гарний код -- це простий код. Кожна окрема частина повинна залишатися простою, з простими обов’язками та взаємозв’язками з іншими частинами системи. Саме так можна зробити наші системи легкими в підтримці, з чистим, простим кодом, який можна тестувати, і забезпечувати високі темпи розробки впродовж усього часу життя системи.

Краса народжується і відкривається у простоті.

(Translations) The Guru Myth - Міф про гуру

Ryan Brush

Оригінал можна прочитати тут.

Кожен, хто займався розробкою достатньо довго, чув питання на зразок такого:

В мене вилітає виключення XYZ. Ти часом не знаєш, в чому справа?

Ті, хто задають такі запитання, рідко додають до опису проблеми слід стеку(stack traces), логи реєстрації помилок, або будь-який контекст, у якому виникла дана проблема. здається, що вони вважають, що ви думаєте якимось інакшим способом, що рішення з’являються перед вами без аналізу, який базується на фактах. Вони вважають, що ви -- гуру.

Таких запитань слід очікувати від людей, не знайомих з програмним забезпеченням: для них системи видаються мало не магією. Що мене турбує -- це такі випадки у спільноті програмного забезпечення. Подібні питання постають при проектуванні програм, наприклад: “Я пишу керування запасами(inventory management).Чи варто використовувати оптимістичне блокування(optimistic blocking)?” Парадоксально, але той, хто задає питання, часто може дати кращу відповідь, ніж той, кого запитують. Той, хто питає, скоріше за все, знає контекст і вимоги, а також може прочитати про переваги і недоліки різних стратегій. Втім, вони очікують від вас розумної відповіді без контексту. Вони очікують чаклунства.

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

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

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