Задачи программиста часто начинаются с идеи, для которой он должен придумать все: как будет выглядеть программа, как будет работать, из каких элементов будет состоять. Для этого ему необходимо системное мышление. Программист должен как бы посмотреть на систему сверху и увидеть, как создать архитектуру программы, которая справится со всеми задачами заказчика, и при желании сможет делать больше, чем нужно сейчас.
Например, когда «Кодабра» работала офлайн, мы создавали личные кабинеты учеников в особом приложении: нужно было выбрать город, в котором живет и обучается ребенок, и для него создать расписание и прикрепить преподавателей. Когда мы стали онлайн-школой, оказалось, что наше приложение больше не подходит: нам не нужно выбирать город, а без этого не ничего не работает. Значит приложение было неправильно спроектировано, разработчик не увидел его как систему.
Предпринимателю также важно увидеть, какую пользу он будет приносить и как будет зарабатывать деньги.
Логическое мышление
Без логического мышления разработчик не сможет придумать и реализовать приложение. Он должен видеть причинно-следственные связи, понимать, как будет работать программа от начала до конца, из каких блоков она будет состоять. Если разработчик понимает это, он сразу видит варианты решений.
Для предпринимателя уметь строить причинно-следственные связи — также жизненно важно. Без этого сложно проследить путь клиента в компанию. Вот он увидел рекламу, позвонил, менеджер по продажам убедил его сделать покупку, покупатель остался доволен продуктом, рассказал друзьям и пришел еще раз.
Для того, чтобы клиент совершил этот путь, в компании должны четко работать отделы маркетинга, продаж и продукта. Логическое мышление помогает предпринимателю видеть эти взаимосвязи и понимать, из каких отделов и элементов должны состоять его бизнес и компания. И особенно здорово, если предприниматель, как и программист, умеет держать все эти элементы в голове и думать сразу над маркетингом, продуктом и продажами.
Гибкость мышления помогает программисту и предпринимателю находить решения в любой ситуации
Разработчики знают, что каждую задачу можно решить миллиардами способов. Программист волен выбирать из огромного набора языков, подходов, фреймворков, библиотек. Даже если разработчик не умеет писать на каждом языке программирования, он, скорее всего, сможет прочитать код, написанный на нем. И уже видя задачу, разработчик понимает, к кому он пойдет советоваться, какой язык и подход выберет.
Гибкое мышление позволяет сказать, что нет ничего невозможного.
Этот навык позволяет предпринимателю быстро понять, успешна его идея или нет, проверить гипотезу и придумать еще тысячу, если провалится эта.
Предприниматель без гибкого мышления постепенно превратит свою компанию в корпорацию: он создаст слишком много правил, по которым нужно работать, и эти правила помешают бизнесу быстро расти и развиваться.
Программисту и предпринимателю важна внутренняя мотивация
Даже если программист получил свои знания и навыки в вузе или на курсах, скорее всего, у него было огромное внутреннее желание. Если ты учишь информатику, чтобы сдать ЕГЭ, то у тебя вряд ли получится стать хорошим программистом. Разработчик участвует в хакатонах, пишет сотни приложений, сидит на форумах. Программистом движет постоянное желание победить машину, заставить ее работать. И на этом пути разработчик совершает тысячи ошибок, учится их принимать, исправлять и прогнозировать.
Предприниматель также существует только на огромном желании строить бизнес самостоятельно, двигаться вперед и набивать шишки. Даже если бизнесмен начинает дело с друзьями, ему нужен внутренний «движок», чтобы не сдаться после первого провала.
Предприниматель с навыками программиста не боится технологий
Предприниматель-программист понимает, что нужно в бизнесе делать руками, а что можно автоматизировать. Например, нанять разработчика, поставить ему задачу и пользоваться преимуществами или использовать готовые сервисы.
Почти любой бизнес упирается в автоматизацию. Хочешь сделать доставку еды — придумай, как будешь собирать заказы, отправлять их на кухню, координировать курьеров, принимать оплату. При этом предприниматель не должен делать это сам: нужно иметь базовое представление, о том, как устроены технологии, чтобы поставить задачу разработчику, оценить ее и не переплатить. Навыки программиста в этом помогают.
Если программист захочет открыть свой бизнес, ему может сильно помешать навык, который был важен в разработке. Это желание ответить на вопрос «Как?»: разработчик будет воспринимать каждую задачу, которая стоит перед бизнесом как головоломку. Но возможно какие-то задачи просто не нужно решать.
Разработчики многое привыкли делать самостоятельно. Но это не делает их предпринимателями: именно умение делегировать постепенно поможет наладить бизнес.
Фото на обложке: Ivan Acedo/shutterstock.com
Источник: rb.ru
Программист должен решать проблемы бизнеса
Недавно вышла статья, мимо которой я не мог пройти — «Программист не должен решать задачи бизнеса». Неожиданно мой комментарий вырос до мини-статьи. Я не согласен с мнением автора статьи, все сказано ниже ИМХО, с удовольствием подискутирую в комментариях. Сразу замечу, что я веб-разработчик, и все примеры я привожу в контексте своего опыта.
Лычки
Думаю стоит начать с лычек. К сожалению, 3 известнейших грейда не имеют четких определений, каждый человек и компания определяют требования индивидуально, границы которых размыты, а иногда это приобретает неожиданные обороты. Поэтому для начала стоит определить, что я понимаю под этими понятиями.
- Juinor — тут меньше всего проблем с определением, начинающий программист, который только-только выучил теорию, возможно, сделал пару pet проектов. Ну или только выпустился из университета.
- Middle — Middle — опытный программист. Разбирается, а не просто знает стек-технологии, которые использует каждый день.
- Senior — это опытный программист, который обладает большим разноплановым опытом, имеет «production» работы на нескольких стеках и обладает «насмотренностью», обладает опытом в смежных областях (например: я считаю нормой, когда Senior Web может обладает навыками администрирования), спокойно может перейти с одного фреймворка на другой или даже с языка на язык без сильной просадки.
Хочешь не хочешь
Программист, хочешь или не хочешь, решает проблемы бизнеса. Всегда, но есть редкие исключения. Нужно понимать, что работа по найму или работа на себя — это всегда товарно-денежные отношения. Бизнесу нужно получать прибыль, с этой прибыли в том числе платится зарплата сотрудникам.
Из этого также следует, что для получения прибыли нужно решать проблемы (ну или можно сказать — решение задач бизнеса). Программисту же нужно на что-то жить, и желательно не плохо. Так же нужно понимать, что «пользу» бизнесу (или решать его проблемы) можно приносить по-разному — как косвенно, так и напрямую.
Как это происходит
Давайте разберем классический кейс, и на его примере посмотрим, как происходит решение проблем бизнеса. Прилетает задача — нужно сделать новый сайт, ничего особенного. Если упростить, то задача прилетает по такой цепочке: руководитель компании -> 1- менеджер -> Тим Лид и дизайнер (как правило два разных отдела, поэтому задача ставиться параллельно) -> senior и/или сразу всем исполнителям. Есть два варианта дальнейших действий:
Кейс 1. Можно просто делать, что скажут, «тупо кодить» — то есть просто все делают в рамках своих прямых обязанностей — Тим Лид обсуждает с бизнесом и заводит задачки в джире, senior продумывает архитектуру и берет на себя наиболее сложные участки, junior верстает, а middle делает обычные задачи, возможно, и сложные вещи вместе с Senior (для упрощения, все Full Stack).
Кейс 2. Перед тем, как взять в работу, организуется несколько совещаний, на которых Senior с Тим лидом, дизайнерами и руководством обсуждают подробно проблему бизнеса. И даже не просто, как решить, а как решить эффективно для всех — и для бизнеса, и для разработчиков, и для дизайнеров. Находится золотая середина, устраивающая всех, и только после этого начинается уже собственно разработка.
Что в итоге?
В рамках первого варианта, когда все «тупо кодят» — в итоге решается проблема бизнеса. Другой вопрос, что она решается не эффективно — 100% срывы сроков, костыли, передача ответственности друг другу, потом, как правило, очень долгое исправление правок и добавление «новых пожеланий заказчика». Все потому, что делали задачу, как поставил ее бизнес.
Никто не сказал, что так не нужно делать — все работали как «винтики» в рамках своих компетенций и не лезли решать проблему бизнеса. Здесь не было команды. После таких проектов, как правило, отношения к разработчикам не очень. Бизнесу важен результат. Умные руководители после этого как раз нанимают Senior, которые готовы решать проблемы бизнеса.
А теперь рассмотрим второй вариант. В этом случае максимальное количество подводных камней, которые случаются всегда, удалось решить командным взаимодействием. Не говоря уже о том, что разработчики могут кардинально изменить реализацию проектов, потому что бизнес может понимать неправильно что для этого нужно. Возможны ли в этом случае проблемы?
Конечно, многое зависит от компетенций, но их точно будет несоизмеримо меньше. В этом случае также решается проблема бизнеса, но эффективно.
Инфраструктурные проекты
В комментариях к статье, ссылку на которую я приводил в самом начале, советуют перейти на инфраструктурные проекты. Что там как раз можно просто кодить. Это обманчиво. Разработчики так же решают проблемы бизнеса, внутренние. Это точно такие же товарно-денежные отношения.
И проблемы такие же, как и при работе над внешним продуктом компании. Другой вопрос, что, как правило, инфраструктурные проекты пишут по первому кейсу. Отсюда и результат. Но даже здесь решаются проблемы бизнеса, и программист принимает участие в решениях.
Команда
Основное отличие первого и второго кейса даже не в реализации, а в команде. И под командой я подразумеваю не пару кодеров, которые реализуют проект, а всю компанию. В первом случае — просто отсутствие команды, во втором ее присутствие — все работают совместно, чтобы получился хороший результат. Понятно, что есть много допущений, но мир в целом не идеальный.
Решение проблем бизнеса != продажи
Я не знаю почему, но часто решение проблем связывают с продажами. Да, зачастую многие задачи с ними связаны, но это только один из факторов и зачастую не самый важный.
Программист не должен задумываться о том КАК будут продавать, но он должен задумываться о том ЧТО будут продавать. От принятия чисто архитектурных решений (которые зачастую Senior и продумывает), скорости отклика, логики работы, дизайна (да, перед его разработкой программисту НУЖНО участвовать в проектировании интерфейса) и т.п. — зависит качество конечного продукта. Даже инфраструктурный проект продают, но внутри компании. От качества конечного продукта зависит эффективность компании и соответственно персональные плюшки (не только материальные).
Исключения
В самом начале статьи, я говорил, что программист хочет не хочет — решает проблему бизнеса, но есть исключения. На мой взгляд единственное исключение, это pet проекты. То, что ты делаешь для себя. С натяжкой можно взять OpenSource, но там часто получается, что твой коммит решает проблему бизнеса, но не твоего.
Вывод
Программист ДОЛЖЕН решать проблемы бизнеса? Да, должен. На уровне своих компетенций, должности и опыта. Программист должен ПРОДАВАТЬ? Нет конечно, хотя навык далеко не бесполезный, особенно на высоких позициях. Можно ли просто кодить?
Конечно, можно. Может ли Senior просто кодить? Нет, на просто кодить можно взять мидла.
Источник: habr.com
Что важнее: знать язык программирования или уметь решать бизнес-задачу?
Много ходит споров о том, какой стоит изучить язык программирования, чтобы сделать карьеру в сфере разработки. Но я глубоко убежден, что языком обязательный набор знаний не ограничивается. К сожалению, не все это понимают.
В обсуждениях задач бизнес и разработчики говорят на разных языках.
С точки зрения бизнеса совершенно не важно, на каком языке будет решена их задача. Бизнес не думает, а возможно, даже не знает о java, go, ruby и других языках и технологиях. Для разработчиков здорово, конечно, когда масштабный и интересный проект начинается с нуля и технологический стек выбирается командой. Но в реальном мире гораздо чаще происходит не так.
Обычно в компании уже есть экспертиза в определенном стеке, от которой ИТ-руководству не хочется отказываться. Причины могут быть совершенно разные, от запрета на “зоопарк технологий” до личных предпочтений лиц принимающих решений. Встречаются и дополнительные факторы вроде потребности в интересных технологиях для команд, ради привлечения и удержания квалифицированных кадров.
Разработчики со своей стороны зачастую высказывают желание развиваться в определенном технологическом стеке. Подкрепляет это намерение большая разница между зарплатами для некоторых языков. Так и появляются люди, которые упорно живут, например, в рамках Java или Python (Go, Kotlin, Scala… список можно продолжать чуть ли не бесконечно) и даже Delphi, не пытаясь посмотреть, а что есть еще.
На мой взгляд, желание углубиться похвально. Но иногда “за деревьями теряется лес” — в процессе этого погружения специалист просто забывает о том, что для бизнеса технологии — лишь инструмент для решения своих задач. В итоге зашоренность на одном технологическом стеке в комплекте с врожденным перфекционизмом (“а давайте сделаем рефакторинг на полгода проекту, у которого нет серьезных планов по развитию, просто потому, что так будет красиво”) не самым лучшим образом отражаются на качестве принимаемых решений.
Моя точка зрения состоит в том, что конкретный язык программирования вторичен. Первичны общее понимание принципов разработки и умение решать проблемы бизнеса — знание подходов и паттернов, которые помогают систематизировать общую работу, опыт применения различных техник, в том числе командных. С таким багажом еще один язык, который нужен в данном конкретном проекте, освоить несложно. У меня перед глазами полно примеров того, как люди переквалифицируются на другие стеки в течении месяца — двух интенсивного обучения. Конечно, сложнее переключаться между языками с разными парадигмами, например с функциональных на объектно-ориентированные, но и здесь нет ничего невозможного, если человек не противится такому переключению “на уровне веры”.
Зная несколько языков, под каждую конкретную бизнес-задачу можно выбирать свой подход к решению — тот, что не просто подойдет, но будет оптимален в данном конкретном случае. И чем больше в арсенале разработчика база этих подходов (языков), тем получается шире взгляд на проблему и мотивированнее выбранный стек. Бизнесу, собственно, это и нужно — получать наиболее подходящее решение для своих задач.
А вот с глубоким знанием одного языка, но без способности решать бизнес-задачи специалист принесет пользу далеко не любой команде. Безусловно, в отдельных проектах глубокие знания “фишек” языка помогают команде в целом добиться большего перформанса. Но чаще член команды, знающий один язык, но не умеющий слушать бизнес, будет лишь тормозить коллег. И кстати, такой “ходячий справочник неочевидных возможностей” зачастую если и нужен в конкретной команде, то только один (делаем выводы о востребованности таких узких специалистов на рынке труда).
Умение решать бизнес-задачи — это на самом деле часть более глобальной сущности — всестороннего опыта работы. Получить его можно как с работодателем, так и в рамках домашних проектов. Правда, на мой взгляд, только бизнес-проекты (где есть заказчики, бюджеты, сроки) могут дать столь необходимую в подобных ситуациях обратную связь, оценивающую качество решения.
А именно это определяет глубину полученного опыта. С домашними проектами такой обратной связи получить просто не от кого: ты сам что-то делаешь и в определенный момент решаешь для себя, что сделал хорошо. На этом все заканчивается. Но когда проект реализуется для бизнеса, недостаточно проработанное решение будет отправлено на доработку, потом еще и еще раз, если это необходимо. И по ходу этих итераций ты неизбежно изучишь несколько подходов к задаче — получишь понимание более высокого уровня.
Одна из составляющих умения решать бизнес-задачи — понимание этой самой задачи. И поскольку довольно часто российские разработчики участвуют в зарубежных проектах, для этого понимания необходимо знание английского языка. В этом вопросе не всегда можно положиться на бизнес-аналитика, поскольку хороших специалистов по этому направлению на рынке не хватает.
Лучше понять бизнес помогает погружение в какую-то отрасль. Когда ты не просто делаешь абстрактный модуль, принимающий, обрабатывающий и отправляющий неизвестному адресату пакеты данных, а реализуешь, допустим, часть сложного биллинга или банковской системы, где есть разные типы пользователей, стандарты и прочие особенности. Знание этих деталей очень ценно.
Такое погружение учит интересоваться тем, что происходит вокруг твоей части задачи. Это помогает искать оптимальное решение. Я знаю специалистов, которые никогда не пойдут работать на задачу, которая нужна непонятно для чего. А в некоторых направлениях развития бизнеса для разработчиков предусмотрено обязательное внутреннее обучение, потому что без погружения в принципе не получится эффективной работы.
В качестве небольшого дополнения для лучшего понимания проблем бизнеса я рекомендую посещать конференции, посвященные конкретной отрасли. Там спикеры делятся опытом, как они решили бизнес-проблему с помощью ИТ-технологий. Зачастую оттуда можно вынести полезную информацию о том, в каком направлении двигаться. Хотя, конечно, никто не требует в деталях повторять чужой опыт.
Я не говорю, что заботиться о бизнес-задачах должен каждый разработчик. Джун только входит в этот круг, на начальном этапе у него уходит слишком много времени на коммуникации с коллегами и изучение того, как решить конкретную проблему. Тут не до расширения кругозора.
Но вот начиная с миддла предыдущий опыт формирует понимание, с какой стороны подходить к задачам определенного типа. На этом этапе уже не возникает вопросов по экосистеме разработки — когда и какие статусы выставлять, как реагировать на код-ревью и т.п. Специалист начинает быстрее справляться даже с незнакомыми задачами — здесь-то самое время “подтянуть” бизнес-составляющую. Фактически сениор от миддла и отличается этим пониманием подходов к решению распространенных проблем бизнеса. И стремление к такому пониманию помогает быстрее перейти на следующий уровень.
Таким образом, я призываю ставить себе цели по развитию одновременно в двух направлениях. С одной стороны, учить языки, а с другой — набираться опыта в решении конкретных задач бизнеса. И в этом развитии надо соблюдать баланс, иначе найти свое место в мире сениоров будет довольно тяжело. А вот куда именно развиваться — в сторону архитектора, очень сильного разработчика или тимлида, — зависит уже от амбиций и личностных качеств (умения работать в команде, ответственности, коммуникабельности и т.п.) конкретного специалиста.
А что вы думаете по этому поводу?
Автор статьи: Сергей Марина
P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.
Источник: spark.ru