Привет Хабр! Зачастую разработчика нанимают для решения бизнес-задач на профессиональном уровне.
Но иногда к мнению разработчиков по вопросам, в которых они более компетентны, чем представители бизнеса, не прислушиваются.
О, Что ты можешь сделать с этим За что Это нужно разработчику, и я хотел бы поговорить.
Счастье и удовлетворение от работы
Счастье – сложное и крайне субъективное понятие.Но я считаю, что счастье связано с получением удовольствия от работы.
В этой статье я хотел бы поговорить о возможном путеводном пути к получению удовольствия от работы разработчиком программного обеспечения: быть профессионалом.
Под этим я подразумеваю не только наличие навыков решения проблем, но и реальную способность применять эти навыки в полной мере.
В мире разработки программного обеспечения существует ряд препятствий, которые мешают вам идти по этому пути к удовлетворению работой.
Например, разработчик, как профессионал своего дела, может полагать, что поддержка системы, проработанная архитектура и правильная организация процессов делают систему более устойчивой к изменениям, тем самым позволяя быстрее разрабатывать новый функционал и адаптироваться к меняющемуся рынку.
- прямая выгода для бизнеса.
Но представители бизнеса могут посчитать это ненужной тратой времени разработчиков.
В чем проблема?
Проблема в том, что предприятия не всегда знают, что для них лучше.Представители бизнеса — менеджеры, специалисты по продуктам, аналитики и многие другие специалисты гораздо лучше разработчиков отвечают на вопрос «что делатьЭ» (работы Н.
Чернышевского к этому отношения не имеют).
Но никто не обладает большим опытом в разработке программного обеспечения, чем разработчики (а также архитекторы, технические менеджеры и другие специалисты, обладающие знаниями и навыками в области разработки).
Их задача — предоставить бизнесу свою экспертизу, обосновать его идеи и ответить на вопрос «как это сделатьЭ» Идея такого взаимодействия лежит в основе методологии Agile ( https://agilemanifesto.org/ ).
Внимательный читатель заметит, как я прибегаю к этому приему.
*argumentum ad auctoritatem (аргумент авторитету).
* Но в мире мнений и субъективных суждений, в котором мы живем, это хороший прием, и я советую вам прибегнуть к нему, в том числе, чтобы донести свою идею как профессионала.
Мнение профессионала о том, что хорошо для бизнеса, субъективно.
Это мнение, которое не может быть истиной в последней инстанции и, как любое мнение, может быть ошибочным — errare humanum est. Однако я считаю, что разработчик должен бороться за те идеи, в которые он верит как профессионал.
Что вы можете попробовать?
Я приведу пример внедрения лучших практик разработки, хотя это касается любой идеи, в которую профессионал верит и считает частью своей экспертизы.Приносить полезные для бизнеса идеи того стоит – это хорошо.
Проблема в том, что внедрение профессионалом своих идей может встретить сопротивление со стороны коллег – других разработчиков, менеджера, высшего руководства и других людей.
Возникает вопрос: готов ли за них бороться разработчик, каковы ставки в этой борьбе и каков ее возможный исход. Все написанное ниже вытекает из того, что разработчик хочет получать удовольствие от своей работы, показать себя как профессионала и максимально использовать имеющиеся навыки, чтобы быть полезным и гордиться проделанной работой.
Предлагаю рассмотреть возможные исходы в следующей шкале: 
Конечно, результат попытки донести вашу идею до бизнеса далеко не двоичен.
Такого быть просто не может, потому что в противном случае разработчик окажется без такого важного инструмента переговоров, как компромисс.
Однако я разделю результаты на возможный успех и возможный провал.
Успех — это когда идея разработчика принимается настолько, что позволяет ему больше применять свой профессионализм и быть довольным проделанной работой.
Есть два случая неудачи: все остается как было, или разработчик меняет работу.
Причины второго опять же иные.
Одна из них заключается в том, что разработчик не желает продолжать заниматься работой, которая не позволяет ему в полной мере применить свои профессиональные навыки и получить удовольствие от работы.
Другим, менее позитивным, может быть то, что разработчик и его коллеги, или начальство, или политики компании в процессе споров дошли до состояния настолько односторонней или взаимной неприязни, что дальнейшее сотрудничество невозможно.
Кого и как убедить?
Если все, кто влияет на ее принятие, согласны с идеей разработчика, то она принимается и результат – однозначный успех.Но эта ситуация выглядит идеализированной, и, скорее всего, возникнут спорные ситуации, которые потребуют разрешения.
Я считаю, что в случае разработки программного обеспечения есть две стороны, которых разработчик может убедить в правильности своего суждения.
Первый горизонтальный — это другие разработчики, так как невозможно реализовать практики, например TDD (разработка через тестирование) или code review, если этим занимается один человек в команде.
Вторая вертикальная — представители бизнеса, поскольку применение лучших практик, особенно когда их внедрение только начинается, требует от разработчиков времени.
Хорошим источником истины, к которому можно обратиться в этих дебатах, является выгода для бизнеса.
Оно выражается прямо или косвенно в денежном выражении.
Будь то скорость разработки, гибкость системы, текучесть кадров или репутация компании.
В случае горизонтальных споров, если не удается донести свою точку зрения всеми возможными методами риторики, разработчик имеет полное моральное право привлечь административный ресурс — обратиться к лицам, принимающим решения, чтобы они поддержали его идею.
А использование административного ресурса – это как раз возможная необходимость разрешения вертикальных споров.
Девелоперу необходимо убедить представителей бизнеса, что его идея принесет пользу компании.
Предприятиям нужна причина тратить ресурсы, поэтому им необходимо дать понять, что внедрение лучших практик развития — это инвестиции.
И здесь инструментами убеждения являются все возможные риторические приемы, а также, возможно, работа с данными, поиск примеров, обращение к авторитету.
Возможно, метод разрешения административных споров придется использовать несколько раз, но здесь разработчику следует задуматься о своей корректности и умении доносить информацию.
Если разработчик прав, но с ним не согласны, значит, он не способен донести до иерархии лиц, принимающих решения, среди которых высока вероятность, что можно принести большую пользу бизнесу.
знакомства с профессионалом своего дела, цель которого – принести пользу бизнесу.
В этом процессе разработчик может не суметь донести свою идею или осознать, что это требует от него слишком больших усилий, несопоставимых с оплатой его труда.
В этом случае возможный путь к работе, которая будет приносить удовольствие, – это смена работодателя.
Заключение
Данная статья представляет собой глубоко субъективное мнение о том, как разработчик может получать больше удовольствия от своей работы, демонстрируя профессионализм и донося бизнесу субъективные идеи, которые разработчик как профессионал считает верными.Статья во многом вдохновлена идеями Agile, книгой «Чистая архитектура» Роберта Мартина, а также моим собственным опытом, опытом и опытом друзей и коллег.
Теги: #Карьера в IT-индустрии #Управление разработкой #Управление проектами #карьера #agile #процессы разработки #лучшие практики #профессионализм #поиск себя
-
«Любовь. Питон. C++». Отчет Яндекса
19 Oct, 24 -
Флеш Гамм! — Встреча Разработчиков Флеш-Игр
19 Oct, 24 -
Ночь.css
19 Oct, 24
