Изучите бизнес и станьте лучшим разработчиком программного обеспечения
Вы ищете что-то новое, чтобы научиться совершенствоваться в качестве разработчика программного обеспечения? Может быть, вы собираетесь изучить этот новый функциональный язык? Или этот новый интерфейсный фреймворк? Возможно, найдите время, чтобы по-настоящему разобраться в машинном обучении, например, в алгоритмах, а не только на использовании готового решения «черный ящик»…?
No.
Скорее всего, это не то, что принесет вам наибольшую пользу. Несомненно, быстрое освоение этой новой структуры может помочь вам работать быстрее. Однако даже более быстрый бег в неправильном направлении не приблизит вас к цели.
Вам нужно научиться чему-то другому - вашему делу!
Потому что, в конце концов, ваша работа - не писать код. Ваша задача - создавать ценность для бизнеса.
Почему мы пишем код
Способ описать ценность бизнеса состоит в том, что это любая ценность, которая способствует успеху компании и долгосрочному здоровью бизнеса. Часто он не может быть измерен напрямую с экономической точки зрения, иногда он может быть даже нематериальным, например, гудвиллом потребителей. В других случаях, например, при повышении производительности, которое снижает затраты на сервер, его гораздо легче измерить.
Как разработчик программного обеспечения вы используете код для создания ценности для бизнеса. Ваша цель никогда не состоит в том, чтобы писать код ради самого себя, точно так же, как работа плотника заключается не в том, чтобы забивать гвозди в дерево, а в том, чтобы строить здания с определенной целью. Код или молоток - это инструмент для создания ценности для бизнеса.
Следовательно, понимание предметной области вашего бизнеса и того, что движет вашей компанией, необходимо для того, чтобы иметь возможность использовать свои навыки для создания ценности для бизнеса.
Чтобы узнать, как работает бизнес вашей компании, есть много преимуществ: мотивация, общение, продуктивность, реализация и решение.
Мотивация
Когда вы поймете цель запроса на реализацию чего-либо и какие ценности он призван достичь, вы будете более мотивированы. Понимание основной цели позволит вам увидеть влияние того, что вы делаете, и то, как это согласуется с бизнесом в целом.
Становится более ясным, где вы и ваша конкретная задача вписываетесь в организацию и какой вклад она вносит в видение и Полярную звезду компании. Знание целей других ролей и отделов, а также того, какую ценность для бизнеса они намерены создать, не только позволит вам лучше поддерживать их, но и увидеть, какое у вас общее видение и как разные части в организация способствует этому.
Коммуникация
Технический писатель или аналитик не только должны владеть своей собственной профессией, но также должны иметь, зачастую глубокое, понимание области, в которой он работает. То же самое и с разработчиком программного обеспечения. Минимум - иметь достаточно знаний в предметной области, чтобы знать словарный запас, эффективно общаться с клиентами и другими разработчиками, используя ту же терминологию и язык.
Кроме того, потребность в общении значительно снижается за счет лучшего понимания деталей, видения контекста и знания предполагаемой информации. Чаще всего это знание решает, можно ли полностью усвоить спецификацию или описание функции, или вам придется слепо реализовать то, что, как вы надеетесь, является правильным.
Вместо того, чтобы тратить всю пропускную способность на устранение недоразумений и пробелов в предполагаемой информации, теперь ее можно гораздо лучше потратить на проактивные действия. Проактивное общение между дисциплинами с акцентом на обмен знаниями с разных точек зрения не только позволит ускорить итерацию идей, но и приведет в конечном итоге к лучшему решению.
Продуктивность
Нам, разработчикам, нравится доставлять вещи - это вершина производительности!
Следуя тому, как общение становится более эффективным, более глубокие бизнес-знания также очень помогают в написании кода. В процессе развития вы сталкиваетесь с нескончаемым потоком решений. Большинство из них сводятся к двум разным вещам; когда и что реализовать и как что-то реализовать.
Большие задачи могут быть расставлены по приоритетам и распределены между членами команды; тем не менее, как только вы разработаете детальную реализацию и начнете кодировать, вы обнаружите новые последствия и крайние случаи, которые влияют на дизайн. Чем лучше вы понимаете зависимости бизнеса от функции, над которой работаете, тем больше вы увидите заранее. Более того, когда вы обнаружите исключение из правила, вы, скорее всего, уже знаете этот ответ, вместо того, чтобы исследовать его в своей организации или обращаться к эксперту в предметной области.
Вы также будете использовать эти знания, чтобы определить микроприоритеты того, как вы подходите к своей реализации, чтобы в первую очередь справиться с возможными неопределенностями, вместо того, чтобы открывать что-то позже, когда вы уже ввели зависимости, что усложняет рефакторинг.
Обладая более глубокими знаниями в области бизнеса, при кодировании становится легче, почти подсознательно, расставлять приоритеты при принятии ежедневных решений. С меньшим общением и большим пониманием приходит уверенность в принятии большего количества собственных решений и автономия. В свою очередь автономия ведет к производительности.
Реализация
Как разработчик, легко зайти слишком далеко, когда дело доходит до создания общих, абстрактных, гибких, расширяемых и многократно используемых вещей, что иногда приводит к чрезмерно сложным реализациям. Чаще всего эти реализации никогда не будут расширяться или использоваться повторно.
Ключ состоит в том, чтобы сбалансировать, когда разрабатывать реализацию, основываясь только на сегодняшних потребностях, и когда принимать во внимание, как она потенциально будет развиваться с течением времени. Обладая опытом в предметной области, вы сможете лучше понять, какой подход может принести наибольшую пользу для бизнеса. Если окно возможностей наступит на следующей неделе, реализация будет отличаться от той, которая потребует месяц (но к тому времени будет совершенно бесполезна с точки зрения создания ценности для бизнеса).
Часто запрос функции заключается в предложении того, что реализовать, обычно подробно описывается с какой-либо спецификацией. Однако спецификации практически никогда не бывает. Вы можете возразить, что исходный код является достаточно подробной спецификацией, не оставляющей места для интерпретации. Следовательно, будут неясные детали, не говоря уже обо всех неписаных предположениях, на которых основана спецификация, и возможных ошибках, которые она может содержать.
Понимая причину реальных «потребностей» и «желаний», вы сможете лучше преобразовать их в конкретные проблемы и решить их.
Спецификация обычно не включает в себя более расплывчатые знания предметной области, не связанные напрямую с самим запросом функции, - знания, которые могут иметь решающее значение для принятия правильного выбора дизайна во время реализации.
Например; В приложении, связанном с финансами, для человека, обладающего базовыми знаниями в области бухгалтерского учета, может быть очевидно, что конкретная переменная никогда не может быть отрицательной. Обычно эти самоочевидные истины не попадают в спецификацию, а усваиваются некоторыми знаниями в предметной области.
Знание этих «очевидных» ограничений может повлиять на то, какую структуру данных использовать, модель базы данных или даже какой алгоритм будет уместен. Этот набор данных малонаселен или нет? Кроме того, такие тривиальные вещи, как возможность выполнять более защитные проверки в коде, даже добавление тестовых примеров, предотвращающих ошибки (поскольку «… этого не было в спецификации!»), Могут существенно повлиять на качество окончательного варианта. реализация.
Решение
По своей природе мы часто делаем поспешные выводы. Часто думают наперед и предлагают решение, основанное только на том, что нам известно. Как разработчик, уверенный в своей области бизнеса, вы можете сделать шаг назад и обсудить цель и ценности, которые должно создать решение. Знание этой основной потребности позволит вам использовать свой технический опыт и знания о существующей кодовой базе, чтобы, возможно, в сотрудничестве с запрашивающей стороной найти еще лучшее решение.
Увидев причину запроса, вы можете подумать о нем, а не просто принять его как данность, выявить возможные недостатки и указать на ошибки.
Получение бизнес-знаний
Итак, как вы подойдете к пониманию своего бизнеса?
Нет одного ответа, который подошел бы для каждой организации; тем не менее, хорошее начало - это поднять свою точку зрения и начать смотреть на то, как вещи, над которыми вы работаете, вписываются в бизнес. Опять же, какова цель приложения, над которым вы работаете, и какие бизнес-ценности оно должно создавать? Как это вписывается в более крупную организацию и, в конечном итоге, в бизнес-модель продукта или услуги?
Также используйте подход сверху вниз. Каково видение компании? Как работает бизнес-модель? Что заставляет клиентов / пользователей проявлять активность в продукте? Какие KPI актуальны на уровне компании? На функциональном уровне? Как то, что вы делаете, помогает изменить эти ключевые показатели эффективности в правильном направлении?
Главное - поговорите с коллегами! Как выглядит процесс продаж? Какой маркетинг успешен, а какой нет и почему? Какие вопросы чаще всего возникают в обслуживании клиентов? Как меняется поведение рынка и как выстраивается стратегия продукта, чтобы воспользоваться этим?
Это всего лишь несколько поводов для разговора, которые помогут вам стать значительно лучшим разработчиком программного обеспечения.
Вам это нравится? Ознакомьтесь с текущими вакансиями в Willa. Мы - финтех-компания, работающая только удаленно, из Европы и США и специализирующаяся на оказании помощи фрилансерам в оплате труда.
