Как компьютерное программирование влияет на бизнес

Недавно вышла статья, мимо которой я не мог пройти — «Программист не должен решать задачи бизнеса». Неожиданно мой комментарий вырос до мини-статьи. Я не согласен с мнением автора статьи, все сказано ниже ИМХО, с удовольствием подискутирую в комментариях. Сразу замечу, что я веб-разработчик, и все примеры я привожу в контексте своего опыта.

Лычки

Думаю стоит начать с лычек. К сожалению, 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 просто кодить? Нет, на просто кодить можно взять мидла.

Согласны?

Проголосовали 745 пользователей.

Воздержался 191 пользователь.

В детстве мои родители говорили, что нужно учить английский язык, который «открывал все двери» и считался гарантией успешной карьеры. Но сегодня, я считаю, что умение программировать обогнало по важности даже знание языков. Этот универсальный навык позволяет собственными силами создавать и выпускать  работающие прототипы сервисов и продуктов, которые можно показывать потенциальным клиентам. Я настолько проникся этой идеей, что сам за один год разобрался с фреймворком для веб-программирования и даже предложил своим коллегам открыть школу кодинга для лидеров бизнеса.

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

Есть в этом и экономическая целесообразность. Представьте, что вы хотите запустить какой-нибудь сервис в виде мобильного приложения. Для этого вам понадобится помощь трех-четырех человек, которые займутся лендингом и разработкой веб-интерфейса, а также программисты приложений (iOS + Android). Зарплата хорошего специалиста начинается от $2 000 — 3 000 в месяц. Пройдет несколько месяцев, пока вы выпустите первую версию продукта, а значит огромные суммы денег придется потратить на тест. Есть проекты, для которых это единственный правильный путь, но, скорее всего, у вас есть идеи, на проверку гипотез которых просто не хочется столько тратить. В свою очередь навык программирования позволяет сделать первую версию своими руками. Ваши мысли обретут пусть простую, но форму, а значит собрать и воодушевить команду будет намного проще, не говоря уже об экономии бюджета.

Я начал с изучения языка программирования Ruby on Rails — на нем написано приложение нашего банка. Кроме того, я подумал, что раз у нас сильная команда программистов и есть возможность задавать им вопросы, почему бы этим не воспользоваться. Конечно, многие ответы можно найти в интернете, но мне было комфортно, что рядом есть реальные люди, готовые помочь, если что-то не будет получаться.

Учиться программированию можно разными способами. Например, мой наставник и директор по технологиям Олег Козырев рекомендует воспользоваться онлайн-курсами, где студенту объясняют тему, а после он пишет код и получает ощущение, что что-то уже умеет. Но такой подход от практики к пониманию общих вещей подходит, разумеется, не всем. Те, кому нужно сначала изучить теорию, стоит начать с прочтения нескольких книг по интересующему языку программирования, затем можно пройти соответствующий онлайн-курс и далее выполнять практические задания, которые так или иначе отвечают потребностям вашей компании. Так, несколько моих «домашних работ» стали применимы в реальности, сегодня эти решения внедрены в работу банка.

Одним из них стал сервис для заказа обедов для наших сотрудников прямо на рабочее место. Клиентскую часть разработала команда штатных программистов, а я применил свои новые знания в серверной части. Задача стояла оптимизировать работу между исполнителями (поварами и бариста) и заказчиками. Создавать отдельное приложение для этого было нецелесообразно, поэтому я решил этот вопрос с помощью бота для Telegram, который отправляет сообщения исполнителям, а они отвечают кнопками со статусом заказа «взят в работу» или «выполнен». Сейчас приложением пользуются 70% сотрудников ежедневно.

В обсуждениях задач бизнес и разработчики говорят на разных языках.

С точки зрения бизнеса совершенно не важно, на каком языке будет решена их задача. Бизнес не думает, а возможно, даже не знает о java, go, ruby и других языках и технологиях. Для разработчиков здорово, конечно, когда масштабный и интересный проект начинается с нуля и технологический стек выбирается командой. Но в реальном мире гораздо чаще происходит не так. Обычно в компании уже есть экспертиза в определенном стеке, от которой ИТ-руководству не хочется отказываться. Причины могут быть совершенно разные, от запрета на “зоопарк технологий” до личных предпочтений лиц принимающих решений. Встречаются и дополнительные факторы вроде потребности в интересных технологиях для команд, ради привлечения и удержания квалифицированных кадров.

Разработчики со своей стороны зачастую высказывают желание развиваться в определенном технологическом стеке. Подкрепляет это намерение большая разница между зарплатами для некоторых языков. Так и появляются люди, которые упорно живут, например, в рамках Java или Python (Go, Kotlin, Scala… список можно продолжать чуть ли не бесконечно) и даже Delphi, не пытаясь посмотреть, а что есть еще.

На мой взгляд, желание углубиться похвально. Но иногда “за деревьями теряется лес” — в процессе этого погружения специалист просто забывает о том, что для бизнеса технологии — лишь инструмент для решения своих задач. В итоге зашоренность на одном технологическом стеке в комплекте с врожденным перфекционизмом (“а давайте сделаем рефакторинг на полгода проекту, у которого нет серьезных планов по развитию, просто потому, что так будет красиво”) не самым лучшим образом отражаются на качестве принимаемых решений.

Моя точка зрения состоит в том, что конкретный язык программирования вторичен. Первичны общее понимание принципов разработки и умение решать проблемы бизнеса — знание подходов и паттернов, которые помогают систематизировать общую работу, опыт применения различных техник, в том числе командных. С таким багажом еще один язык, который нужен в данном конкретном проекте, освоить несложно. У меня перед глазами полно примеров того, как люди переквалифицируются на другие стеки в течении месяца — двух интенсивного обучения. Конечно, сложнее переключаться между языками с разными парадигмами, например с функциональных на объектно-ориентированные, но и здесь нет ничего невозможного, если человек не противится такому переключению “на уровне веры”.

Зная несколько языков, под каждую конкретную бизнес-задачу можно выбирать свой подход к решению — тот, что не просто подойдет, но будет оптимален в данном конкретном случае. И чем больше в арсенале разработчика база этих подходов (языков), тем получается шире взгляд на проблему и мотивированнее выбранный стек. Бизнесу, собственно, это и нужно — получать наиболее подходящее решение для своих задач.

А вот с глубоким знанием одного языка, но без способности решать бизнес-задачи специалист принесет пользу далеко не любой команде. Безусловно, в отдельных проектах глубокие знания “фишек” языка помогают команде в целом добиться большего перформанса. Но чаще член команды, знающий один язык, но не умеющий слушать бизнес, будет лишь тормозить коллег. И кстати, такой “ходячий справочник неочевидных возможностей” зачастую если и нужен в конкретной команде, то только один (делаем выводы о востребованности таких узких специалистов на рынке труда).

Умение решать бизнес-задачи — это на самом деле часть более глобальной сущности — всестороннего опыта работы. Получить его можно как с работодателем, так и в рамках домашних проектов. Правда, на мой взгляд, только бизнес-проекты (где есть заказчики, бюджеты, сроки) могут дать столь необходимую в подобных ситуациях обратную связь, оценивающую качество решения. А именно это определяет глубину полученного опыта. С домашними проектами такой обратной связи получить просто не от кого: ты сам что-то делаешь и в определенный момент решаешь для себя, что сделал хорошо. На этом все заканчивается. Но когда проект реализуется для бизнеса, недостаточно проработанное решение будет отправлено на доработку, потом еще и еще раз, если это необходимо. И по ходу этих итераций ты неизбежно изучишь несколько подходов к задаче — получишь понимание более высокого уровня.

Одна из составляющих умения решать бизнес-задачи — понимание этой самой задачи. И поскольку довольно часто российские разработчики участвуют в зарубежных проектах, для этого понимания необходимо знание английского языка. В этом вопросе не всегда можно положиться на бизнес-аналитика, поскольку хороших специалистов по этому направлению на рынке не хватает.

Лучше понять бизнес помогает погружение в какую-то отрасль. Когда ты не просто делаешь абстрактный модуль, принимающий, обрабатывающий и отправляющий неизвестному адресату пакеты данных, а реализуешь, допустим, часть сложного биллинга или банковской системы, где есть разные типы пользователей, стандарты и прочие особенности. Знание этих деталей очень ценно. Такое погружение учит интересоваться тем, что происходит вокруг твоей части задачи. Это помогает искать оптимальное решение. Я знаю специалистов, которые никогда не пойдут работать на задачу, которая нужна непонятно для чего. А в некоторых направлениях развития бизнеса для разработчиков предусмотрено обязательное внутреннее обучение, потому что без погружения в принципе не получится эффективной работы.

В качестве небольшого дополнения для лучшего понимания проблем бизнеса я рекомендую посещать конференции, посвященные конкретной отрасли. Там спикеры делятся опытом, как они решили бизнес-проблему с помощью ИТ-технологий. Зачастую оттуда можно вынести полезную информацию о том, в каком направлении двигаться. Хотя, конечно, никто не требует в деталях повторять чужой опыт.

Я не говорю, что заботиться о бизнес-задачах должен каждый разработчик. Джун только входит в этот круг, на начальном этапе у него уходит слишком много времени на коммуникации с коллегами и изучение того, как решить конкретную проблему. Тут не до расширения кругозора. Но вот начиная с миддла предыдущий опыт формирует понимание, с какой стороны подходить к задачам определенного типа. На этом этапе уже не возникает вопросов по экосистеме разработки — когда и какие статусы выставлять, как реагировать на код-ревью и т.п. Специалист начинает быстрее справляться даже с незнакомыми задачами — здесь-то самое время “подтянуть” бизнес-составляющую. Фактически сениор от миддла и отличается этим пониманием подходов к решению распространенных проблем бизнеса. И стремление к такому пониманию помогает быстрее перейти на следующий уровень.

Таким образом, я призываю ставить себе цели по развитию одновременно в двух направлениях. С одной стороны, учить языки, а с другой — набираться опыта в решении конкретных задач бизнеса. И в этом развитии надо соблюдать баланс, иначе найти свое место в мире сениоров будет довольно тяжело. А вот куда именно развиваться — в сторону архитектора, очень сильного разработчика или тимлида, — зависит уже от амбиций и личностных качеств (умения работать в команде, ответственности, коммуникабельности и т.п.) конкретного специалиста.

А что вы думаете по этому поводу?

Автор статьи: Сергей Марина

P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.

В мире до сих пор живо устаревшее представление о программисте: он пишет код, работает чаще всего один и редко берет на себя задачи, не связанные с разработкой. Но сейчас айтишники умеют работать в команде, знают, как сделать продукт, а не просто программу, понимают, что нужно другим людям. Программист может стать предпринимателем, если захочет. 

Дарья Абрамова, основательница и CEO онлайн-школы цифрового творчества «Кодабра», и Антон Катков, франчайзи «Кодабры» в Самаре, рассказывают, почему программисты могут легко развить предпринимательские способности.

Программисту и предпринимателю важны системное и логическое мышление

Системное мышление

Задачи программиста часто начинаются с идеи, для которой он должен придумать все: как будет выглядеть программа, как будет работать, из каких элементов будет состоять. Для этого ему необходимо системное мышление. Программист должен как бы посмотреть на систему сверху и увидеть, как создать архитектуру программы, которая справится со всеми задачами заказчика, и при желании сможет делать больше, чем нужно сейчас. 

Например, когда «Кодабра» работала офлайн, мы создавали личные кабинеты учеников в особом приложении: нужно было выбрать город, в котором живет и обучается ребенок, и для него создать расписание и прикрепить преподавателей. Когда мы стали онлайн-школой, оказалось, что наше приложение больше не подходит: нам не нужно выбирать город, а без этого не ничего не работает. Значит приложение было неправильно спроектировано, разработчик не увидел его как систему. 

Логическое мышление

Без логического мышления разработчик не сможет придумать и реализовать приложение. Он должен видеть причинно-следственные связи, понимать, как будет работать программа от начала до конца, из каких блоков она будет состоять. Если разработчик понимает это, он сразу видит варианты решений. 

Для предпринимателя уметь строить причинно-следственные связи — также жизненно важно. Без этого сложно проследить путь клиента в компанию. Вот он увидел рекламу, позвонил, менеджер по продажам убедил его сделать покупку, покупатель остался доволен продуктом, рассказал друзьям и пришел еще раз. 

Для того, чтобы клиент совершил этот путь, в компании должны четко работать отделы маркетинга, продаж и продукта. Логическое мышление помогает предпринимателю видеть эти взаимосвязи и понимать, из каких отделов и элементов должны состоять его бизнес и компания. И особенно здорово, если предприниматель, как и программист, умеет держать все эти элементы в голове и думать сразу над маркетингом, продуктом и продажами. 

Гибкость мышления помогает программисту и предпринимателю находить решения в любой ситуации

Разработчики знают, что каждую задачу можно решить миллиардами способов. Программист волен выбирать из огромного набора языков, подходов, фреймворков, библиотек. Даже если разработчик не умеет писать на каждом языке программирования, он, скорее всего, сможет прочитать код, написанный на нем. И уже видя задачу, разработчик понимает, к кому он пойдет советоваться, какой язык и подход выберет.

Этот навык позволяет предпринимателю быстро понять, успешна его идея или нет, проверить гипотезу и придумать еще тысячу, если провалится эта. 

Предприниматель без гибкого мышления постепенно превратит свою компанию в корпорацию: он создаст слишком много правил, по которым нужно работать, и эти правила помешают бизнесу быстро расти и развиваться. 

Программисту и предпринимателю важна внутренняя мотивация

Даже если программист получил свои знания и навыки в вузе или на курсах, скорее всего, у него было огромное внутреннее желание. Если ты учишь информатику, чтобы сдать ЕГЭ, то у тебя вряд ли получится стать хорошим программистом. Разработчик участвует в хакатонах, пишет сотни приложений, сидит на форумах. Программистом движет постоянное желание победить машину, заставить ее работать. И на этом пути разработчик совершает тысячи ошибок, учится их принимать, исправлять и прогнозировать. 

Предприниматель также существует только на огромном желании строить бизнес самостоятельно, двигаться вперед и набивать шишки. Даже если бизнесмен начинает дело с друзьями, ему нужен внутренний «движок», чтобы не сдаться после первого провала. 

Предприниматель с навыками программиста не боится технологий

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

Почти любой бизнес упирается в автоматизацию. Хочешь сделать доставку еды — придумай, как будешь собирать заказы, отправлять их на кухню, координировать курьеров, принимать оплату. При этом предприниматель не должен делать это сам: нужно иметь базовое представление, о том, как устроены технологии, чтобы поставить задачу разработчику, оценить ее и не переплатить. Навыки программиста в этом помогают. 

---

Если программист захочет открыть свой бизнес, ему может сильно помешать навык, который был важен в разработке. Это желание ответить на вопрос «Как?»: разработчик будет воспринимать каждую задачу, которая стоит перед бизнесом как головоломку. Но возможно какие-то задачи просто не нужно решать.

Разработчики многое привыкли делать самостоятельно. Но это не делает их предпринимателями: именно умение делегировать постепенно поможет наладить бизнес. 

Фото на обложке: Ivan Acedo/shutterstock.com

Программист не должен решать задачи бизнеса +22

Программирование, Карьера в IT-индустрии

---

Рекомендация: подборка платных и бесплатных курсов Smm — https://katalog-kursov.ru/

Вступление

Это будет статья про нытье, разочарование, выгорание и возрождение.

Эту статью я пишу в первую очередь для себя, чтобы разложить по полочкам свое понимание определенной области на данный момент.

Возможно пройдет время и я изменю свое мнение. Адекватные дискуссии приветствуются.

Определенно хочу сказать спасибо fillpackart за его статьи. Я часто не согласен с его суждениями и выводами, но, пожалуй, именно его публикации подтолкнули меня к размышлениям. Итогом некоторых таких размышлений стала эта статья.

Также вышла интересная дискуссия с TimeCoder, в которой я понял, что мне не хватает продуманных аргументов. «Как собака — все чувствую, а выразить не могу!»

Кто ты вообще такой?

Можно сказать, что я программист по призванию. Увидел компьютер первый раз года в 4, батя на работе дал мне порисовать на черно-белом мониторе в чем-то типа Paint. Я был поражен и осознал что хочу уметь командовать машиной, абсолютно и безраздельно. Потом были книжки дома типа «Познаем компьютер», первая программа на QBasic в 13 лет, институт по специальности «ПО ВТ и АС» с квалификацией «Инженер» и работа. В продакшен я писал код на VBA, JS, T-SQL, PL/SQL, Битрикс (прости Господи) и как основной язык C#.

В общем обычная крепкая веб-макака. А еще я не хочу решать задачи бизнеса.

Почему ты так решил?

Когда я был молодой, то узнал про разделение программистов по уровню квалификации — junior, middle, senior. А так как я хочу уметь командовать машиной, значит моя цель — стать сеньором! Не ради лычки, а чтобы заслуженно обладать таким же количеством знаний и умений.

Шло время, я читал умные книжки, набирался опыта от старших товарищей.

И кто такой сеньор?

На работе меня потихоньку начали таскать на совещания. Сначала на обсуждение частей сервиса. Потом на интеграцию сервиса с другим сервисом. Потом на обсуждение дизайна UI. И потом я осознал, что сижу среди менеджеров, они обсуждают увеличение конверсии и воронку продаж, и поглядывают на меня, хотя я вообще бэкенд.

Тогда я спросил своих знакомых сеньоров, нормально ли это, мне ответили «Конечно, это обязанность сеньора». А это реально крутые ребята, я хотел быть как они. И я начал ходить на совещания.

И было все больше совещаний и мне говорили «Надо думать, как решать задачи бизнеса».

И тут я понял, что сеньор — это тот, кто решает задачи бизнеса.

А что значит решать задачи бизнеса?

На одной работе мне однажды выдали сеньорскую лычку. Хотя там все поголовно были сеньорами, я все равно обрадовался, и погрузился в сеньорство с головой. Спорил с менеджером проекта, и аналитиком, и дизайнером, чтобы сделать пользователю удобнее и комфортнее, хотя это было некрасиво с точки зрения кода и архитектуры. Код проекта получался все хуже. Начальство ставило задачу всей команде, а спрашивали потом с меня. «Ну ты же сеньор». Я был связующим звеном между менеджером, базистом, фронтом, аналитиком и дизайнером. И еще писал бэкенд.

И как-то это все начало меня напрягать и я подумал «Наверно надо найти другую работу».

Собеседования выглядели примерно так:

— Вы же претендуете на позицию senior software developer?
— Да. А какие обязанности у senior software developer?
— Решать задачи бизнеса, разумеется.

Оказалось, что везде одно и то же.

Начальство, знакомые сеньоры, рекрутеры, интервьюверы мне говорили «Настоящий программист должен решать задачи бизнеса. Бизнес зарабатывает деньги. Ты должен делать такой продукт, который бы приносил деньги. А иначе за что тебе платить?».

И тут я понял, что решать задачи бизнеса — думать о том, как принести работодателю больше прибыли.

И в чем трагедия?

А я не хочу об этом думать.

Эй, а за что тебе тогда платить?

А вот наконец и вылез культивируемый миф, то что сеньор позиционируется как Настоящий Программист! То, к чему должны стремиться все разработчики.

Мне кажется, что я открыл заговор работодателей.

Бизнесу выгоден этот миф. «Эй, парень, хочешь лычку? Мы назовем тебя Настоящий Программист, а ты думай в первую очередь о том, как будет легче продать то, что ты напишешь.»

И самое плохое то, что некоторые скудоумные разработчики сами в это верят и поддерживают миф.

«Я решаю проблемы бизнеса, мне выдали сеньорскую лычку, значит я Настоящий Программист, а ты нет!» — маркетинговый буллшит.

Поясни на примерах

Программист это такое смешение инженерии и творчества.

Инженер, который строит мост, должен ли вообще задумываться о том, как этот мост будет окупаться? Вообще нет, его задача — спроектировать и построить мост, который уложится в сроки, в смету и простоит указаное по плану количество лет.

Авиационный инженер не должен думать, как же компании надо будет окупать рейсы. Он должен построить эффективный, мощный, удобный в обслуживании двигатель.

Художник с детства мечтал о том, как его рисунок на коробке хлопьев будет способствовать увеличению продаж?

Врач-хирург просто делает операцию, чтобы спасти жизнь пациенту, а Настоящий Врач-Хирург делает операцию и продумывает, как бы ее сделать так, чтобы пациент заплатил больше денег больнице?

Смешно? Бред? А с программистами почему-то работает.

Сам-то не сеньор, вот и бесишься!

«Раб мечтает не о своей свободе, а о своих рабах».

Я осознал что мне наплевать, как бизнес будет монетизировать мой труд. Пусть этим занимаются менеджеры, продажники, маркетологи и product owner.

«О нет, ты теперь не сеньор!» — вообще наплевать, лычки никак не влияют на квалификацию разработчика.

Я просто стараюсь хорошо делать свою работу, писать качественный и легко поддерживаемый код.

Давайте вспомним Linux. Скажите что Линус плохой разраб, потому что он не задумывался о монетизации.

Я бы посоветовал разработчикам, которые думают о проблемах бизнеса, открыть свой бизнес и думать о нем, это будет полезнее для всех.

А всем остальным желаю заниматься любимым делом в комфортной обстановке и не вестись на всякие льстивые уловки.

Спасибо что прочитали.

Так как я и программист, и предприниматель, то у меня в голове возникли параллели между одним и другим делом.

Осталось из этого только сделать вывод, что каждый программист — это хороший предприниматель. Но нет. Хотя многие хорошие предприниматели — программисты.

Обновлено: 22.03.2023

Традиционная ошибка большинства людей, занимающихся эффективностью бизнеса — использование ограниченного набора инструментов. Например, работа только с процессами. Или только автоматизация. Или — лишь система мотивации. Или, вообще, только постановка стратегических целей.

Бизнес-программирование — это единая методика, в которой используется= разнообразный инструментарий работы с целями, системами управления, процессами, автоматизацией и мотивацией.

Методы взаимно проникают и дополняют друг друга, принося, в итоге, намного более полезный результат. Что важно — намного меньшими усилиями, как по времени, так и по затратам.

Статистика

Бизнес-программирование: Синхронность и асинхронность процессов

Любому программисту понятно, что такое синхронность и асинхронность. Вот насколько это понятно программисту, настолько это непонятно и обычным разработчикам процессов. Синхронные действия процесса — те, которые выполняются в основном потоке, в рамках одного экземпляра процесса. Ключевое отличие синхронного режима: следующее действие начинается только тогда, когда завершено предыдущее. Соответственно, пока одно действие не завершено, процесс стоит колом. Асинхронные действия — те, которые выполняются паралл.

Бизнес-программирование: Конфликт ‘один — много’

Конфликт <один — много> распространен, в первую очередь, среди людей, занимающихся описанием процессов, но не прилагающих особых усилий для того, чтобы получилось что-то вразумительное. <Один> — это когда действие процесса выполняется над одним объектом. Например, обработка одной заявки на закуп, одного заказа покупателя, одной заявки на расход денег. <Много> — это когда действие процесса выполняется над большим множеством объектов, например — сразу над пачкой заявок, портфелем заказов и т.д. И <один, и <м.

Бизнес-программирование: Портянки

Программисты любят рисовать отчеты-портянки. Если нужен отчет по продажам — вывалят всю таблицу продаж, с контрагентами, номенклатурой, организациями, договорами, суммами и количествами. Все бы ничего, только с помощью такого отчета сложно управлять. Анализировать — можно, если есть куча свободного времени. А у кого есть куча свободного времени? У аналитика есть, например. Ладно, если он по должности аналитик. Есть ведь по призванию души аналитики. Должность у него, например, менеджер по продажам, но прода.

Бизнес-программирование: Описание процессов

Когда за разработку процессов берутся люди, далекие от понимания алгоритмов, часто возникают ошибки. Причем, на словах, в понимании разработчиков, процесс получается вполне себе годным, но на бумаге он становится нерабочим. Люди думают — да ладно, все же понимают, как надо работать, а бумажка — это так, для отписки. Но время идет, люди меняются — уходит разработчик процесса, меняются сотрудники, исполняющие процесс и настает момент, когда единственным источником информации становится та самая бумажка. А он.

Бизнес-программирование: Принцип ‘Айсберг’

Все знают, что такое айсберг — большой кусок льда, который плавает в океане. Все помнят, что не так с айсбергом — видна лишь небольшая его часть, которая над поверхностью воды, остальное скрыто. И сколько его там, этого остального — никто не знает. Аналогичная ситуация — с данными в автоматизированных системах. Мы, обычно, видим сами данные. Документы, вроде накладных на отгрузку или поступление, перемещения, платежки и т.д. Справочники — номенклатуру, контрагентов, подразделения. Задачи видим, и обычные, .

Бизнес-программирование: Автоматизация контроля границ

Процессы на границах лучше автоматизировать. Звучит банально, но такая рекомендация далеко не всегда выполняется. До сих пор достаточно распространены ситуации, когда переход процесса через границу осуществляется без использования автоматизированных систем. На многих предприятиях в ходу бумажные служебные записки, заявки, распоряжения и т.д. Разумеется, это касается не только границ между отделами — бумажками грешат и сотрудники одной службы. Если один сотрудник передает другому процесс в бумажном виде, от.

Бизнес-программирование: Метод плавательных дорожек

Метод плавательных дорожек — неплохое средство для анализа процессов. Это — именно аналитический метод, т.к. он не говорит, что надо изменить в процессе, но позволяет легко и быстро увидеть потенциальные источники проблем. В основном применим для кроссфункциональных процессов — тех, в которых участвует два и более функциональных подразделений, либо команд — в общем, там, где процесс переходит через какие-то границы. Рассмотрим на примере. Допустим, у нас есть некий процесс — закупки под заказ. Менеджер отд.

Программирование — это процесс и искусство создания компьютерных программ. Сюда входят написание кода и сценария, составление алгоритма, разработка программного обеспечения, вёрстка, дизайн и многое другое. Основа программирования — специальные языки, на которых записываются исходные тексты программ.

Зачем нужно программирование

К 2020 году программирование настолько глубоко вошло в быт, что люди перестали замечать, как изменилась жизнь. Сотни тысяч привычных вещей не существовали бы без программирования или были бы гораздо менее удобными в использовании. Привычные бытовые приборы: микроволновая печь, стиральная машина — работают благодаря заложенным в них программам.

Всего 50 лет назад невозможно было представить, как легко будет найти любую необходимую информацию, насколько экономнее станет использоваться время, затрачиваемое на решение некоторых задач.

Поначалу для каждого крохотного действия приходилось создавать программу с нуля . Сейчас же программ написано такое множество, что в их разнообразии трудно ориентироваться. Например, чтобы смонтировать клип, придётся потратить часы на изучение существующих видеоредакторов и выбор подходящего.

Наше время диктует новые условия буквально в каждой области деятельности. Если компания хочет облегчить жизнь себе и своим клиентам, обойти конкурентов, то будет внедрять компьютерные технологии. Музыкальная индустрия и кино, мультипликация и игры, мобильная связь, банковское дело, дизайн и журналистика — все области тесно переплетены с программированием и используют специальные программы на разных этапах работы.

Языки программирования и сферы их применения

Перед людьми, заинтересованными в изучении программирования, встаёт задача выбора языка. Языки программирования требуют от программиста различного уровня внимания к деталям при реализации алгоритма. В зависимости от области применения и поставленных задач, подбирается подходящий язык программирования: удобный и простой. Правильный выбор языка сэкономит вам время и увеличит производительность.

Мнения о количестве существующих языков программирования расходятся. Каждый день не только совершенствуются старые языки, но и разрабатываются новые, поэтому выбор для изучения велик. Однако наиболее востребованные, популярные и высокооплачиваемые последние несколько лет неизменны. По данным Github, это:

Стоит также обратить внимание на старый добрый язык разметки HTML, вырвавшегося в 2020 году в десятку лидеров TypeScript в рейтинге PYPL, и на перспективных новичков Kotlin, HCL и Go.

Некоторые из них используются для фронтенд-разработки, это HTML, CSS и Javascript. Другие применяются в бэкенде: PHP, Python, Go, Ruby.

Доступность обучения программированию

Изучение языков программирования открывает новые возможности и перспективы для каждого человека. Развитие навыков поможет найти работу мечты в каждой стране мира или же работать удалённо.

Работа программиста высоко оплачивается и будет востребована ещё много лет. Бюро статистики труда прогнозирует к 2026 году 30-процентный рост занятости в области разработки программного обеспечения. Некоторые компании охотно берут способных новичков, в других требуется опыт работы или сертификат об окончании обучения.

Обучение программированию не проблема в нынешних реалиях. Существуют обучающие программы, интенсивы, онлайн-курсы , которые помогут новичку легко вникнуть в суть, и с нуля изучить программирование до того уровня, который позволит работать в интересующей компании.

Согласно исследованиям, Python, HTML и Javascript доступнее всего для изучения и имеют низкий порог вхождения новичков. Они же, по данным исследований TIOBE и PYPL, самые востребованные. Однако не все компании отдают предпочтения традиционному подходу к разработке программного обеспечения, интерес к новым языкам растёт. Знать базовые языки, следить за тенденциями развития новых и по возможности изучать их особенности и есть задача грамотного программиста, смотрящего в будущее.

На бесплатном интенсиве «Основы программирования» вы сможете понять основные принципы большинства языков программирования и выбрать, в какой сфере вам интересно развиваться. Переходите на сайт ниже и регистрируйтесь на мастер-класс, по итогам которого вы получите сертификат и материалы для дальнейшего обучения.

Фриланс – не самый простой способ начать зарабатывать большие деньги. Создание качественного портфолио поможет стартовать и получить первые отзывы. На крупных биржах труда вроде UpWork высокая конкуренция – бывает даже полезно сделать несколько работ за небольшую сумму, лишь бы получить рейтинг и ускорить рост карьеры. Но не ограничивайтесь одним фриланс-маркетплейсом. Наращивайте охват аудитории, используйте навыки коммуникации и знание иностранного языка.

Даже если вы работаете на постоянной работе, стоит попробовать. Дополнительный опыт не помешает, а клиентская база будет постепенно расти. Начать можно с наших публикаций:

Конечно, в работе на полный день в офисе есть свои минусы. Например, привязка к месту и работа по расписанию. Но в то же время это один из самых стабильных и оплачиваемых видов деятельности. Подтверждение легко найти в нашем разделе Вакансии. Многие компании готовы к частично или полностью удаленной работе – не так уж важно, где с ноутбуком находится разработчик, если есть результат.

Ч тобы иметь хорошо оплачиваемую постоянную работу, нужно уметь себя презентовать и показать опыт. Если вы только начинаете свой путь, опыт можно получить и на позиции стажера или участвуя в Open Source проектах.

О различных стратегиях прохождения собеседований и опыте работы в компаниях мы пишем в постах с тегом Трудоустройство:

Существует множество маркетплейсов, где можно выставить на продажу код своего плагина без заботы о дополнительном маркетинге. На международном рынке наиболее известны сайты австралийской платформы Envato:

– сток тем и шаблонов для WordPress и других движков. – сток программного кода скриптов для сайтов.

1. Высокая комиссия платформы.
2. В приёмке проекта наиболее важен дизайн.
3. Можно долго получать отказы модераторов без каких-либо объяснений.

YouTube – это телевидение нашего времени, где каждый может создать свой канал. Для начала д остаточно смартфона или веб-камеры ноутбука. Можно делать скринкасты кода, вести видеоблог о новинках в мире IT, создавать плейлисты-курсы. Наиболее близкий формат можно подсмотреть в наших подборках YouTube-каналов по различным темам:

Когда ваш канал станет популярным, привяжите функцию «Спонсорство» или предложите зрителям подписаться на канал Patreon, где они будут получать доступ к видеоролика раньше, чем на YouTube.

Если вы любите поболтать, но вам не нравится снимать себя на камеру или утомляет монтирование видео, начните подкаст. Для него не нужно столько свободного времени, сколько для съемок видео – некоторые умудряются записывать подкасты по дороге на работу. Естественно, подкасты – не самый быстрый способ заработать деньги, но так вы сможете получить аудиторию для других проектов и прослыть экспертом в своей области.

Но помните, что клиент будет платить только, если приложение полезно. Поэтому не тратьте время зря – прежде, чем задумываться о нюансах архитектуры, постройте прототип и измерьте интерес потенциальных пользователей:

Если вы владеете ценными знаниями из популярной области или по теме, которая еще не заполнила просторы интернета, разработайте курс. Чтобы сделать качественный контент, нужно хорошо знать тему, о которой вы рассказываете. Придется потратить время, но это того стоит.

Для продажи курса можно использовать собственный сайт либо платформу образовательных маркетплейсов, где позаботятся о маркетинге и продвижении вашего продукта. Платформа заберет процент от дохода, зато вы сможете преподавать, ни о чем не беспокоясь.

Блоги давно обрели популярность и вряд ли скоро ее потеряют, особенно в сфере информационных технологий. Ведь программный код – это тоже текст, как и то, что вы сейчас читаете.

Блогинг, как способ заработка денег, потребует усилий для формирования первой аудитории. Если вы планируете зарабатывать деньги только на рекламе, понадобится огромное количество посетителей. Вместо простого показа рекламы к блогу можно прикрутить другие методы заработка, например, спонсируемые посты и партнерские программы. М ожно писать и в блоги других людей и сайтов – некоторые платят за гостевые посты, оригинальные статьи и переводы. Это не всегда афишируется, но ничто не мешает спросить.

Развив свой блог или курс, вы поймете, какой информации особенно не хватает вашим подписчикам – вы можете обобщить свои знания в виде книги. Эту книгу можно рекламировать в том же блоге, YouTube-канале или курсе. В наше время не нужно думать об издании бумажной книги – всё можно сделать электронно. Подходящим ресурсом для издания книг о программировании является LeanPub.

В постах с тегом GameDev мы регулярно освещаем полезные инструменты для разработки игр, такие как Unity и Unreal Engine. Разработка игр – прибыльный бизнес, для вхождения в который не требуется большая команда разработчиков. К примеру, вы можете создать мобильную мини-игру с микроплатежами, опубликовать ретро-игру, сделанную на PICO-8 или воспользоваться одним из наших гайдов:

Некоторые думают, что искать баги – это для крутых хакеров. Знание языков программирования в этом деле помогут, но можно начать даже без них. Узнайте о ТОП-10 OWASP и распространенных проблемах безопасности веб-приложений. За нахождение некоторых из них вам хорошо заплатят. Вдохновляющий старт обеспечит наша статья Как получить 15600$ от Google за найденные баги.

В разделе Мероприятия мы регулярно публикуем события с призовыми деньгами. Нужны лишь твердые навыки, творческое мышление и надлежащая мотивация – неизбежно придётся проигрывать.

В процессе участия в соревновании количество ваших IT -друзей и знакомых резко увеличится, на вас обратят внимание рекрутеры. Одно из больших преимуществ – возможность создать мощное портфолио и выглядеть лучше в глазах компаний. Если займете почетное место, то не только заработаете деньги, но и станете «рок-звездой» – на собеседованиях будет проще вести переговоры о зарплате.

Чтобы победить на хакатоне, следуйте 10 советам.

Персональный коучинг работает не только в фитнес-индустрии, психологии, личностном росте и бизнесе. Если вы являетесь экспертом в своей теме, вы можете найти много людей, желающих ускорить рост своей карьеры в IT -индустрии. Вы можете предложить менторство, помочь стать программистом и получить первую работу. Если найдете несколько учеников, это может стать отличным вариантом подработки. Такой подход такжеи поможет завести новых друзей и получить удовольствие, делая чью-то жизнь лучше.

Поздравляем! Теперь вы знаете, как сделать свои навыки более прибыльными. Как вы могли заметить, многие из описанных способов лучше работают в связке: материалы из блога легче переработать в книгу, чем написать с нуля, а наиболее целеустремленные ученики ваших курсов или слушатели подкаста будут заинтересованы в персональном менторстве . В любом случае, все усилия будут идти на пользу вашей репутации и карьере.

Программирование занимает одну из значительных ниш в современном мире. Это не просто способ заставить работать «железяки», но и поставить себя на путь развития своих способностей. Но, прежде чем мы разберём все полезные свойства, следовало бы разобраться с терминологией. Программирование — область деятельности, направленная на разработку программного обеспечения, которое, в свою очередь, направлено на улучшение и облегчение человеческого быта, промышленной деятельности, сферы услуг и технологического прогресса.

Одним из детей программирования можно назвать сервис виртуальный номер для смс. Благодаря ему вы можете отправлять, получать, осуществлять массовую рассылку смс даже без наличия телефона. Аналогично виртуальному номеру телефона существует и факс-номер. Вы можете купить себе для офиса эту услугу и получать факс, например, на электронную почту.

Что касается пользы в изучении и тренировки навыков программирования, то можно смело сказать, что этот род деятельности не только приносит хороший заработок, но и неплохо развивает мышление и логику. Как и любая точная наука, программирование развивает аналитические и дедуктивные способности, абстрактное мышление. Можно смело сказать, что эта отрасль дает развитие человека в целом. Навыки создания программ, позволят обрести такие качества как упорядоченность мыслей, строгая организация и постановка решения проблем практически любого уровня сложности и характера.

Существует множество примеров успешных людей, которые достигли высот профессиональной деятельности, которые никак не связана с программированием, именно благодаря тому, что в своё время имели некоторую практику написания кода в колледжах и университетах.

Нынешнее программирование многогранно и используется в таких важных сферах как строительство, бизнес и экономика, медицина, биология и физика. Большой процент физического труда в промышленности заменен на машинный и роботизированный труд, который управляется посредством программного обеспечения, что обеспечивает существенный прирост скорости, точности операций и эффективности производства. Такое богатство разнообразия применений обеспечивается солидным выбором языков программирования, у каждого из которых есть свои плюсы и минусы.

Только представьте, сколько пользы приносит программирование в наши дни, ведь использование в множестве развивающихся направлений науки и инфраструктуры, это далеко не всё. Как известно, программирование — это тяжелый умственный труд, а труд сделал из обезьяны человека. В условиях нашего, быстроразвивающегося мира, именно умственный труд определяет место человека в обществе.

Читайте также:

  

• Как сделать переходник usb vga

  

• Oracle чем varchar отличается от varchar2

  

• Xbox 360 ошибка 800704cd

  

• Точка входа в процедуру cmtimerangemakefromdictionary не найдена в библиотеке dll coremedia dll

  

• Как проверить подлинность сертификата pci dss