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

Я деякий час був розробником. Я далеко не найкращий там. (Коли я сиджу сама в цій кімнаті, мені цікаво, чи я навіть тут найкращий.) Однак я зрозумів свої інструменти, і я повірив на свою здатність міркувати та вчитися.

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

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

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

Для мене це читання та розуміння кодових баз.

Я кажу, що з двох ключових причин:

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

2. Спочатку побудуйте фундамент. Тож, якщо у кожного є своя ментальна модель того, якими є ці конкретні умови та процеси, як ви будуєте свої? Для мене, і я думаю, що для багатьох програмістів я будую свої ментальні моделі найкраще з коду. Код має закономірності. Кодекс має абстракції. У мене є великий досвід прийняття коду та побудови з нього ментальної моделі. Після того, як я, по крайней мере , неясне форму того , що існують речі , і як вони пов'язані, то я можу говорити діловим людям. Тоді я можу задати правильні запитання і краще вписати їх відповіді в пазл.

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

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

1. Бюджет свого часу і поважайте їх, але отримуйте стільки, скільки зможете.
2. Вам потрібно буде задати питання. Вони не думають, як програмісти, і все розбивають і мають повне розуміння того, як інформація стосується один одного.
3. Не підробляйте, як ви розумієте. Якби ви знали стільки, скільки інших ділових людей, вони змусили б вас робити обидві роботи. Дивіться №2.
4. Не чекайте документації. Запропонуйте багато похвал, якщо ви коли-небудь отримаєте якісь.
5. Утримайтеся від критики. У процесах та процедурах можуть бути надлишки та інші потенційні показники ефективності, але це може бути причиною. Дізнайтеся, чому, але не вражайте, коли вони кажуть: "Ми завжди робили це так".
6. Будьте ввічливі, ласкаві і поділіться своїми закусками. Ви маєте справу з людьми. Привітайся. Запитайте, як вони роблять. Запитайте, чому вони пішли у галузь, як довго вони були з компанією.

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

Я б порекомендував прочитати книгу під назвою "Елементи ефективного мислення" Едварда Бергера та Майкла П. Старбірда. Це пов'язано з розумінням нових концепцій загалом, але я думаю, що це стосується і цієї ситуації.

Ось кілька цікавих моментів із книги:

Оволодіти основами

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

Нехай помилки будуть вашими посібниками

Іноді допомагає задавати питання, явно неправильні, щоб ви могли розкрити свою нерозуміння. (Наприклад: Ви маєте на увазі, що адміністратори мають доступ до кожного документа? О. Чому?)

Навчіть або поясніть це іншим

Коли ви спробуєте навчити це комусь іншому, ви почнете розкривати, де у вас є проблеми з розумінням.

Сподіваюся, що це допомагає!

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

Як я почав це вирішувати?

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

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

Це призводить мене до питань і сумнівів. Я набираю всіх із них і, нарешті, встановлюю зустріч з тим, хто може вирішити мої сумніви.

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

Вивчення> Сумніви> Запитання> Відповіді> Розуміння (повтор циклу знову і знову)