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

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

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

Узнать, почему я так думаю

Вступление

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

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

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

Определенно хочу сказать спасибо 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. Скажите что Линус плохой разраб, потому что он не задумывался о монетизации.

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

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

Программирование бизнесу: как мы делаем ЭТО?

bd image

Есть такая идиома в английском — «it’s not rocket science», буквально — «это не ракетостроение». Мы обычно в таких случаях говорим — «это не высшая математика». То есть: «Хэй, это же просто!». Не заумно, не заоблачно — доступно и понятно. Наша цель такова: клиентам должно быть понятно все то, что мы с помощью программирования делаем для их бизнеса. Наша работа не должна быть для них «загадкой», когда они даже не знают, за что именно платят.

Поэтому мы уверенно говорим: программирование it’s not rocket science для них и для нас. Это просто: просто оптимальный способ решения бизнес-задач с помощью наших умений и знаний.

Как это было устроено раньше?

Еще лет 10−15 назад у разработчиков (и у нас в том числе) преобладали задачи, связанные именно со спецификой программирования. Например, реализовать обмен сообщениями или почтовый сервис, написать блог или форум. Были специалисты, которые занимались написанием баз данных, организацией хранения информации и т. д. Подобные задачи относятся к инфраструктурным. Реальную выгоду от их решения пользователь, как правило, «пощупать» не может — но без них невозможно запустить ни один проект. Тогда, лет 10−15 назад, можно было считать, что программирование — это действительно «rocket science»: разработка шла на уровне технологии, а заказчик ни слова не понимал.

Факт: В Индии была широко распространена практика оценки труда программиста по количеству написанного им кода: чем больше строк — тем лучше специалист работает и, следовательно, выше оплачивается. Находчивые разработчики специально удлиняли все, что могли, тем самым породив еще одну идиому — «индусский код».

Как это работает сегодня?

картинка с милыми котятками

C одной стороны, сегодня программирование — это кое-что «пострашнее» ракетостроения. В нем одна цель — чтобы ракета летела, а для программистов бизнес ставит столько невероятно разноплановых задач, как будто каждый из них ракетостроитель-вокалист-экзорцист, имеет водительские права для БелАЗа, черный пояс по дзюдо, кубок Сибири по рыбалке, научную степень экономиста и отлично печет печенюшки. (Ну хорошо, печенюшки иногда не нужны.)

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

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

Это и лежит в основе нашего рабочего манифеста: само программирование не так ценно, как решение задач с помощью программирования.

Как организована наша работа?

И пока программистов в вузах учат по-прежнему «писать код», профессиональная сфера требует от них уже немного других навыков, главный из которых – это коммуникация. У всех на устах, к примеру, философия Agile (от англ. «проворный»). По науке, это семейство «гибких» подходов к разработке программного обеспечения. По факту – это программирование, основанное на адекватности подхода к работе, человеческом отношении между разработчиком и клиентом и отлаженной коммуникации на всех уровнях.

Стереотип о «бородатых диких программистах», которые кодят, сидя в уединённой пещере, уходит в небытие. Напротив, бизнес-сообщество активно перенимает опыт и технологии работы (например, тот же agile) у IT-бизнеса. Оказалось, что эти вот «интроверты» отладили коммуникации с клиентом так, что у них есть чему поучиться.

— Сейчас перед нами стоит проблема ускорения процесса производства. Для ее решения необходимо, чтобы коммуникация шла напрямую. Многие детали проекта доступны только разработчику. И если тот не будет замотивирован выдавать заказчику обратную связь – проект будет страдать. Программисту никак нельзя действовать по принципу «мне сказали – я написал», необходимо вникать в то, как будут пользоваться его разработкой, уметь вовремя сообщить, что «так это работать не будет». Раньше на такую обратную связь часто «забивали», программистам говорили: «Ваше дело код писать». А сейчас к этому начинают прислушиваться, эффективная коммуникация рассматривается как один из главных источников ускорения производства. — Евгений Тюменцев, генеральный директор «Hello World! Technologies»

Согласно современным требованиям, программисту необходимо развивать не только его hard skills, то есть исключительно профессиональные навыки, но и soft skills, «мягкие навыки» – к ним относятся, в том числе, ответственность, учтивость, умение слушать, говорить и договариваться. Акценты смещаются, профессия программиста трансформируется — и, собственно, спрос с них уже не такой: «пишет код – и хорошо». Вопрос в том, решает он задачи или нет.

Мы в «Hello World! Technologies» не только пишем и говорим об этом, но и следуем своему манифесту и отвечаем на современные запросы бизнес-среды. И на примере своих кейсов показываем, как именно мы можем, применяя знания в области программирования, решать задачи, стоящие перед бизнесом.

Жизнь после кода. Из программистов в бизнес-консультанты, менеджеры, продавцы

Image via Shutterstock

Меня зовут Михаил Завилейский. Формально я — генеральный директор DataArt. Но, на самом деле, просто из один многочисленных руководителей компании — ведь самого главного начальника у нас нет. В DataArt я отвечаю за организационное развитие. До прихода сюда 10 лет работал в IT — в основном программистом, но также немного и менеджером.

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

Причины перехода

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

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

Наша индустрия развивается от содержательно сложных проектов к разнообразно сложным. Почти все содержательно сложные проекты (когда ясно, что именно нужно сделать, но сделать это трудно) были реализованы в IТ-индустрии уже много раз: так, было создано много хороших бухгалтерий, банковских систем; встроенные программы работают в машинах, самолетах — всё это уже есть.

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

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

Карьера инженера

Вот типичный карьерный путь программиста, тестировщика или другого IT-специалиста:

Итак, кто-то начинает работать с младшей позиции. На самом деле, джуниор отличается от синьора главным образом тем, что обычно получает часть компенсации своего труда не деньгами, а опытом и обучением. Таким образом, на джуниорах компании зарабатывают больше, а джуниор выбирает компанию правильно, если там может многому научиться. По сути, отличия между джуниором и синьором на 80% — в психологических качествах, и лишь на 20% — в знаниях и опыте.

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

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

Конечно, синьору может быть интересно бесконечно долго, но, как показывает опыт, многие из них перемещаются на другие позиции:
— Эксперт;
— BC — business consultant (бизнес-консультант);
— PM — project manager (менеджер проектов);
— SM — sales manager (менеджер по продажам);
— AM — account manager (аккаунт-менеджер);
— OM — operations manager (операционный менеджер).

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

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

Репутация, а затем квалификация

Как я себе представляю профессионала? На мой взгляд, профессионал состоит из двух частей:
1) Квалификация — умения, опыт, навыки;
2) Репутация — то, что о нем знают окружающие.

По моим наблюдениям, большая часть профессионалов предпочитает качать квалификацию. Они изучают новые движки, читают книги по программированию, участвуют в состязаниях программистов — в общем, повышают профессиональную квалификацию всеми возможными способами. Большинство представляют свою карьеру именно так: «Я всему научусь, окружающие увидят, как хорошо я всё делаю, и меня повысят». Но, как показывает опыт, обычно людей не слишком интересуют другие люди (разве что, другими интересуются профессиональные менеджеры, ответственные за развитие персонала). Люди обычно полагают, что всё, что происходит без их прямого вмешательства, происходит само собой. Например, если вы написали идеальный код, — ну, вам повезло, просто так получилось. И вашей заслуги в этом никто не увидит, если только вы сами не расскажете о трудностях, которые пришлось преодолеть.

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

Отсюда — первое правило развития: Репутация должна опережать квалификацию.

Проявить себя

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

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

Итак, однажды у нас в компании появился не очень хороший коллега-программист. Я познакомился с ним, когда он вызвал команду ОС «удалить всё из текущего каталога» из сервера приложений (тогда это был ASP) — так он удалил из «system32» всё, что можно было удалить. После этого сервер продолжал работать какое-то время (файлы, которые в тот момент использовались, не удалились), но он никогда не перезагрузился бы и скоро упал, как только захотел бы сделать что-нибудь новое и загрузить какой-нибудь dll из system32.

Я уже не помню, чем закончилась эта история. Но, как бы то ни было, этот коллега продолжил развиваться в компании, но сильных технических задач ему уже не доверяли. Зато ему всегда больше всех было надо, чтобы всё было хорошо: он никогда не верил, что нельзя сделать хорошо ту или иную вещь, или что заказчик не может быть удовлетворен. Таким образом, его репутация складывалась из так называемых soft skills, социальных навыков. Мы знали, что мышление у него не слишком инженерное, но зато клиент-ориентированное, результат-ориентированное, в чем-то то перфекционистское, — при этом он отличный партнер, который помогал команде показывать лучший результат. Теперь, по прошествии 18 лет, этот человек, Алексей Миллер, сидит в Нью-Йорке, возглавляет все продажи в DataArt.

Бывает, что мы можем проявить себя гораздо лучше не в кодировании, а в чем-то другом. Это совершенно нормально — в современном IТ-мире для этого есть очень много возможностей.

Изменение мотивации

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

Есть чудесный цикл, поддерживающий всех профессионалов счастливыми, который я назвал «do-check-enjoy» («сделать-проверить-радоваться»). Мы что-то делаем, мы можем это проверить, и нам даже не нужно постороннее мнение — мы видим, что мы это сделали круто. Такие события, повышающие самооценку, случаются постоянно. Один из моих любимых авторов, Дэвид Майстер, писал, что самооценка у всех профессионалов исходно занижена — именно это из-за этого профессионалы несчастливы на простой работе, а постоянно стараются учиться чему-то новому, создавать для себя новые вызовы и что-то себе доказывать. Я могу сказать, что это совершенно точно относится ко мне и к большому количеству моих коллег. Цикл «do-check-enjoy» действительно дает много счастья. И чем больше ты начинаешь смещаться в сторону более сложных и коллективных ролей, тем меньше остается возможностей наслаждаться этим циклом.

У меня нет хорошего примера на этот счет из области IТ, но я могу привести отличный пример из области медицины, который приводят все врачи, когда читают лекции по деонтологии (медицинской этике). Однажды известного врача, впервые в мире сделавшего пересадку сердца и сделавшего много таких операций впоследствии, Кристиана Барнарда, спросили: «Доктор, спасли ли вы чью-либо жизнь наверняка?» Доктор Барнард ответил, что не знает, но всё-таки одну жизнь он точно уж спас. Он рассказал, как в молодости поехал лечить одного фермера, болеющего пневмонией и находящегося в тяжелом состоянии. Жена фермера не верила в благоприятный исход и хотела прибегнуть к народному средству: убить козу и завернуть фермера в ее шкуру. Однако доктор Барнард сказал, что сначала он всё же еще попытается спасти жизнь фермера средствами общепринятой медицины. В итоге доктор Барнард сумел за одну ночь спасти фермера, и, выйдя наутро из дома, проходя мимо козы, которую хотели убить, произнес: «Коза, я спас тебе жизнь!»

Этот пример показывает, как непросто быть врачом: нужно тешить себя мыслям, что ты действительно помогаешь людям, хотя обычно даже не знаешь, наверняка это или нет. А если ты инженер, точно знаешь, что такой-то код заработал в 10 раз быстрее, — и это факт. Если же ты менеджер, продавец или аналитик (а это — командная работа), увидеть результат своих действий вне взаимодействия с большим количеством людей невозможно. Если никто ничего не слил, всё получилось, все молодцы, и ты, наверное, тоже. А когда что-то пошло плохо, иногда знаешь, что это точно твоя вина.

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

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

Путь эксперта

Одна из самых сладких для разработчиков возможность — стать экспертом. Роль идеального IТ-эксперта лежит где-то на пересечении трех возможных ролей:

— Decision maker — тот, кто принимает решения. Эти люди берут на себя ответственность.

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

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

В IТ в работе с бизнес-заказчиками нужна, в идеале, роль, которая лежит на пересечении этих трех, — и это самая сложная роль. Такого рода людей очень мало.

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

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

Если же ситуация предполагает большое количество людей, важно помочь правильно определить границы ответственности, и это — самое трудное. Сейчас самые развитые компании, работающие в IТ, стараются перейти от продажи часов и усилий к продаже решений. Связано это с тем, что мы никогда не произведем столько же часов, сколько производится в Индии или Китае, ведь часы работы, которые стоят в 5 — 10 раз дороже, чем те же часы в Азии, продать очень трудно. Поэтому все компании хотят, чтобы цена формировалась в зависимости от ценности услуги для клиента, а не количества потраченных часов. И здесь, конечно, границы ответственности, о которой нужно договориться заказчику и исполнителю заказа, — большой вопрос. Умение нащупывать эту границу — высший уровень в бизнесе и управлении.

Теперь еще пара комментариев, кто такой эксперт. Есть неправильное понимание эксперта — когда считают, что эксперт — это просто тот, кто самый умный или просто что-то лучше знает. Но это не всегда так. Чтобы быть экспертом, нужно знать очень много в какой-то узкой области.

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

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

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

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

Путь менеджера проектов

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

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

Поэтому управление ожиданиями — самая главная функция менеджера проектов, в отличие от остальных менеджеров в сфере IТ.

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

Менеджер проектов это не тот, кто нарисовал план и строго ему следует, а талантливый человек, который понимает, что ожидаемый результат подвижен, будучи зависим от разных факторов, и в соответствии с этим постоянно вносит изменения в план и управляет ресурсами, стараясь попасть в цель на пересечении многих изменчивых факторов. Менеджер проектов — не тот, кто просто управляет подчиненными (хотя сейчас идеальная команда — team of peers, команда равных, где нет явных начальников), а тот, кто влияет на огромное количество людей вокруг и на их представления, что нужно делать, — так, чтобы они сошлись в одной точке и остались довольны друг другом. Это — самое важное.

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

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

Если же клиент воспринимает любые изменения в штыки, нужно быть устойчивым и обстоятельным по отношению к любым просьбам об изменении объема проекта. Если идти на поводу у таких просьб, всё для этого проекта может закончиться плачевно. Например, в гибкой методологии разработки один из главных принципов — «fail early», согласно которому неуспех должен случиться как можно раньше. В общении с клиентами из бизнес-культуры очень важно как можно быстрее проверить все возможные засады, которые могут привести к разрушению отношений.

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

Путь продавца

Это — самый трудный путь и, по моим наблюдениям, самый непопулярный среди бывших программистов. Во-первых, это связано с тем, что продавец не обязан быть компетентным в инженерном деле, и поэтому продавцы часто приходят с других позиций и мест. Во-вторых, у инженера, в отличие от продавца, эффективность труда намного выше. Хороший инженер не может себе позволить допускать большой процент брака, на мой взгляд, у хорошего инженера более 90 % работы выполняется очень успешно. У продавца же производительность труда намного меньше: при большом количестве потенциальных покупателей лишь немногие что-то у вас покупают. В норме подписывают контракт менее 10 % контактов, попавших в поле зрения продавца. Поэтому инженеру обычно психологически очень трудно перейти в продажи, не насмотревшись на процесс продаж и не привыкнув.

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

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

Путь аккаунт-менеджера

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

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

Самое крутое — бизнес-мышление, которое позволяет думать вместе с клиентом или даже без клиента, как сделать хорошо. Бизнес-мышление позволяет делать внешние и внутренние стартапы, получать бюджеты там, где их не было, позволяет убедить клиента сделать что-то большое и новое и рискнуть чем-то. Часто говорят, что бизнес-мышление присуще людям, которые в конце видят деньги и понимают, как до них дойти. В каком-то смысле это верно, но в современном мире денег всё больше, но в то же время всё больше и страхов отсутствия взаимопонимания. Поэтому те, кто работает в аккаунт-менеджменте на высшем уровне, производят смыслы: задаются вопросом «а какой смысл делать такой-то проект?». Если привести аргументацию, что смысл в этом есть, все делают этот проект.

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

Путь операционного менеджера

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

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

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

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

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

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

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

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

�� Подобається Сподобалось 2

До обраного В обраному 1

Влияют ли программисты на бизнес компании?

Невероятная история путеводителя «Автостопом по Галактике» начинается очень просто. Она начинается с человека, если быть точным, с землянина, который знал о своей судьбе не больше, чем чайный лист знает об истории Вест-индской компании.

The Hitchhiker’s Guide to the Galaxy by Douglas Adams

Компания А владеет проектом с хорошей стабильной бизнес моделью. Вы приходите как разработчик и начинаете выдавать качественный код. Компания А развивается и растет, на день рождения директора приглашают Lady GAGA и она танцует приват для всех желающих. Это ваша заслуга?

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

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

С другой стороны, не имея никаких мотиваций кроме денег, программисты становятся легко заменяемым ресурсом.

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

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

А вы задумываетесь о своей реальной ценности для компании?

P. S. Этот материал написан под вдохновением от статьи Коляна и вбросом Макса, обычно мне хватает 140 символов.

�� Подобається Сподобалось 0

До обраного В обраному 0

DOU Подкаст

Найкращі коментарі пропустити

Как раз недавно об этом думал.

К переоценке своей значимости будут более склонны те люди, которые что-то из себя представляют, но работают в команде «джуниоров». Некоторые работодатели (да что там некоторые, я бы даже сказал, что большинство) по разным причинам предпочитают именно такую схему работы. Соответственно, человек ощущает свою значимость в компании, банально, по причине, именно, своей значимости, но только для этой компании. Что в отрыве от внешней среды будет давать ложную картинку, человек верит в свою значимость и необходимость в нём не только в этой компании, а и в других тоже. Человека трудно заменить в компании, но его ценность на рынке может быть гораздо ниже. Про значимость «джуниоров» вообще не имеет смысла говорить.

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

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

Поработав много времени по первой схеме и ощутив в полной мере преимущество второй схемы работы, я врядли уже смогу работать как-то по-другому. Как можно ощущать свою значимость, видя, как под боком вкалывают твои коллеги, и, как всегда кажется со стороны, гораздо больше и продуктивнее тебя 🙂 Как можно ощущать свою персональную значимость, видя как команда тестеров тестируют твой продукт в таких условиях, о которых ты даже не подозревал, находят то, о чём ты даже не догадывался. Команда админов, которые по телефонному звонку уже несутся по корридору для того, чтобы насетапить всё, что ты попросил. Команда менеджеров по работе с клиентами экранирует от тебя 95% всей ненужной информации и трёпа, чтобы ты работал более продуктивно. Какая уж тут личная значимость? 🙂 Но личный успех каждого формирует успех команды и успех всей компании.

Много как-то получилось . 🙂

Неделя вбросов на ДОУ?

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

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

— раз компания делает бизнес wold-wide, то чего она что хочет платить как «туземцам» — это адекватно? Почему не на уровне западных комманий? Или наши тупее чем ихние? Или компании жаднее?

Раз у компании нет денег — так и нужно говорить: «мол бедные мы пока», а не сетовать на «прергретый» рынок и «космические» зарплаты програмеров.

Пограммер ведь он тоже человек 🙂 Тоже хочет жить достойно! — иметь хорошую квартиру, обстановку, *новую* машину, возить семью отдыхать в не Цюрюпинск, а хотя бы в Турцию, хотя бы не в Rixos, но в 5*

Да! Если парень молодняк и хочет быть seinor и тметь все сразу — это не совсем логично, но есть люди, которые работают и по 10 лет в индустрии. И если они не могут себе позвоить — качественный отдых, жилье, транспорт — то на ФИГА ТАКАЯ РАБОТА? Пускай боссы сами пишут свои программы!

Да! мне по фиг по больщому счету откуда компания берет деньги — кредитованные или заработанные. Но я не претендую на какое либо партнерство — и потому не должен «разделять» все трудности! Компания платит — человек работает. Платит мало — ищет другую работу 🙂

Say «be mercenary» !

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

Не заменимых людей нет. в приемлимые сроки.
Кодеры — не влияют. Кодеров валом, можно заменить.

Тимлиды, архитекторы и просто светлые головы — еще как влияют. Представьте на секундочку что они «Встали и ушли». Или пусть даже сказали — «Мы уходим» и ушли через 2 недели.

Лучше не знать за сколько и в каких обьемах продается продукт который делают «вон те парней и 2 девчушки тестировщиц». Жаба удавит нафиг.
Подавляющие большинство работает на ставке.
Не нравится — вперед делай свой стартап.

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

А вообще для компании ценный каждый сотрудник. Если он работает.
Но брать его «в долю» никто конечно не будет.

106 коментарів

Alexander Kuznyak Delivery Manager Consultant в сам себе режиссёр 18.07.2011 18:49

Влияют ли работники Киевавтодор-а на качество дорог в городе?

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

Хм. Один программист плохо сделал сайт мегафона и данные ушли в сеть. Один программист сделал ошибку в расчетах разгонной массы ракеты и три спутника глонасс утопли. Один программист сделал ошибку в программе для Therac. Парочка программистов не смогла договориться, считать в метрах или дюймах, и разбила Orbiter. Еще один программист ошибся — и вебкойн упал на 30%. Влияют ли программисты на бизнес? :))

Vladimir Prokopchuk Team Lead в IBM 18.07.2011 22:41

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

Ну и вообще, нечего важные расчёты всяким программистам доверять :о)

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

Vladimir Prokopchuk Team Lead в IBM 18.07.2011 23:59

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

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

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

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

Во времена советские по «секретной» статистике было известно, что количество простоев по понедельникам на порядок выше других дней недели. Лично в молодости столкнулся с изобретением похмеляющихся токарей: отвинтить чуток провода от датчиков-концевиков.

При выключенном станке провода прекрасно прозваниваются, при включенном — за счёт вибрации шестерёнок контакт периодически теряется и выбивает тепловое реле от перегруза двигателя. Да и КГБ не придерётся: винтик типа просто расшатался. Правда сейчас ставят камеры слежения.

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

Вот Гарри Каспаров рассказывал, как он обыграл Deep Blue:

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

Авария на Саяно-Шушенской никогда не повториться на Днепрогесе. В Сибири умники свели мозги управления всеми турбинами в одно помещение, которе и было развалено, в результате все турбины пошли в разнос.
На Фукусиме при модернизации внедрили рацуху: в целях экономии сделали общее управление закачкой воды охлаждения реакторов. Результат известен.
Ну и причём тут программисты?
Программу вы оттестируете хоть 200 раз, но ей надо подыгрывать моделью внешней среды, которую частенько не делают вообще, или делают упрощённо, и обычно её программируют люди с более низкой квалификацией и составляют отчётик: вот проверили
1) Если Земля крутиться, все норм
2) Если солнце встает, все норм
Итого: всё норм.
Но тут рядовой Вася Пупкин после дембельской пьянки прикорнул в стыковочном узле и забыл бушлат, что нарушило выход на расчётную траекторию и не позволило состыковать Союз с МКС.

Mike Gorchak Graphics Device Driver Developer в QNX Software Systems 19.07.2011 07:35

Парочка программистов не смогла договориться, считать в метрах или дюймах, и разбила Orbiter.

Там были не дюймы или метры, а там были килограммы и фунты. Ошибка была накопительная при постоянном переводе туда-сюда. С дюймами такого быть просто физически не может, т.к. его величина фиксирована, а вот фунта — нет. Даже при жёстком фиксировании 1 фунт = 0.45359237 кг, ошибка появится довольно-таки быcтро.

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

Artem Senior .NET full-stack 17.07.2011 13:09

Успех проекта во многом зависит не только от девелоперов, сущ роль все-таки — менеджмент проекта, даже гуру проггеры если им поставить неправильные цели — заведут проект в тупик, хотя код может быть будет первоклассным, только никому и даром не нужным.

Конечно влияние отдельно взятого программиста на успех компании присутствует особенно если компания маленькая, а если компания такая как Гугл? — то влияние рядового программиста настолько мало что можно сказать =0. За провал по шапке дадут менеджерам в случае успеха — тож самое менеджеры будут купаться в бонусах.

Кроме того в идеале системе бизнеса устраняется влияние отдельных личностей, т.е. заменяемость всех и каждого

начиная от низа и заканчивая СЕО и даже самим собственником. Компании к-е вышли на фондовые площадки могут быть куплены и проданы при этом это не должно существенно сказываться на результатах деятельности.

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

«Не спрашивай, что компания может сделать для тебя, спроси, что ты можешь сделать для компании» )))

Вообще, если есть мысли «На сколько я важен для компании?», значит что то не так.

Следовало бы предложить более животрепещущую симметрично-обратную тему:
«Влияют ли бизнес-компании на программистов?»

Мой скромный личный опыт учит: начальству никогда верить нельзя.

Пока у вас нет работы, возможно найдете время на статью

Если я безработный, это не значит, что у меня много свободного времени. Вот вы же «С++»-ник, а работаете СЕО, вот и я, где-то наоборот, пишу на С++ в своё удовольствие, и совсем не вирусы-боты за деньги, а простой 2D движок на 10000 спрайтов.

Oleksiy Gremlyatskyi Software Test Engineer 15.07.2011 23:32

Если разработчик занимается промышленным шпионажем и добивается включения в функционал Top Secret-функций компании-конкурента, то — да: влияет.

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

Админам: Ну кнопку [-] тут делать не будут, но вот кнопку [+100] можно было бы добавить.

Alexander Kuznyak Delivery Manager Consultant в сам себе режиссёр 15.07.2011 19:28

Тезисно:
-Программисты влияют на качество продукта в какой-то степени (и, кстати, не только они).
-Есть очень много факторов которые влияют на бизнес.

-Качество продукта входит в эти факторы и занимает свою нишу, но не яляется полностью доминирующим.

Вывод:
Программисты (все) влияют на бизнес, но в не большой степени.

Программист (в отдельности) влияет на бизнес, но в еще меньшей степени.

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

А если совсем откровенно — вопрос в теме поставлен не корректно.

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

Так разгоните всех ваших программистов, че?

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

Вам за это деньги платят, разве нет?

Платят, и что с того?

Alexander Kuznyak Delivery Manager Consultant в сам себе режиссёр 15.07.2011 16:59

По-моему у Макса и ко. задача сущесnвенно повысить кол-во «человекопостов» в день этими самыми «вбросами»!

Главное «не количество, а какчество», а сраче-посты — это только количество, без качества.

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

Что вы узнали нового (совсем нового) из этого обсуждения? Или из 2 предидущих?

UPD: предидущих == предыдущих (. наверно)

Коментар порушує правила спільноти і видалений модераторами.

К сожалению из ваших комментариев ничего

Автор в несознанку уходит. Совершенно очевидно что серебрянный волк спрашивал не о своих коментах.

Хороший попытка. ~~Ваше кунг-фу~~ Ваша техника троллинга почти так же хороша как и моя 🙂

Обычно в таких ситуациях пишут «слив засчитан»,

но разница в том что вы не просто участник срача на форуме, вы взялись писать «статью», а это уже ответственность.

Мысли в слух (типа риторический вопрос):

Почему колонки на ДОУ используются всякими SEO и CEO для раскрутки себя и своих контор? А потом люди еще спрашивают: «Почему у нас идут в депутаты не честные люди?»

>Почему колонки на ДОУ используются всякими SEO и CEO для раскрутки себя и своих контор? А потом люди еще спрашивают: «Почему у нас идут в депутаты не честные люди?»

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

Коментар порушує правила спільноти і видалений модераторами.

Вот пример мнения, даже больше мысли:
www.developers.org.ua/. sskih-narodnyh

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

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

Alexander Kuznyak Delivery Manager Consultant в сам себе режиссёр 15.07.2011 18:17

Писать «разрешено» только программистам? 🙂

ну и еще раз — сделай лучше, если хочется «качества».

Одесса:
— Простите, а что вы делаете что бы наще море было чище?

— В отличии от вас мы туда ничего не делам.

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

Vladimir Prokopchuk Team Lead в IBM 15.07.2011 16:28

Любая нормальная компания старается минимизировать такое влияние. Это абсолютно нормально, так как в IT программист это «мясо», и он должен «мясом» и оставаться. И ничего обидного тут нет. Влияние рядового сотрудника на бизнес компании — огромный риск, и любой здравомыслящий менеджер будет пытаться минимизировать этот риск.
В правильно построенном бизнесе не должно быть незаменимых звеньев.

Влияет ли отдельный солдат на судьбу взвода? Очень влияет. А на судьбу батальона? Если комбат не полный профан — то мизерно.

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

«Не влияют» и «Влияют не настолько сильно как думают» — это разные вещи 🙂
Проблема в том что многие люди не привыкли ~~к командной игре~~ думать как часть команды:

Когда команда побеждает — это заслуга всех, когда команда проигрывает — это ошибка всех.

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

Вам никто не мешает уйти на нормальный рынок 😉

Мысль № 1: Давайте сравним это с оффлайн бизнесом: вы строите обычную гостиницу, на сколько успех вашего бизнеса зависит от строителей? Да и на 100% зависит, и на ни сколько зависит, потому что построить дом — совершенно не значит построить гостиницу. А теперь давайте представим что строим уникальный ультра-современный мост, а вот тут успех полностью зависит от строителей, да и строителей в мире таких всего-то парочка. Программисты выполняют роль строителя-конструктора в современном мире, просто одни строят здания по уже плюс-минус понятным технологиям, а другим приходится использовать «нанотехнологии» и проявлять не только способность «кирпичик к кирпичику», а и как-то изощряться.

Мысль № 2: Перегретость рынка. Да, для украинских заказчиков всё сложнее и сложнее заказывать адекватную разработку за приемлемые деньги, а связано это с тем, что современный мир практически стёр границы на рынке разработки, и заказчик из США, где ёмкость рынка совсем другая, где другой объём экономики, спокойно заказывает разработчиков из Украины, именно и только поэтому цены на разработку ростут, ростут цены программистов, а мы глаза выпячиваем, когда нам показывают стоимость часа разработки.

Согласен, если смотреть на ситуацию абстрактно. Когда программист — это только программист, который только дает код.

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

С другой стороны «влияет или не влияет» — это тоже абстрактно. В какой степени влияет? Даже 20% влияния программистов не перекроют 80% влияния руководства. Так что если вектор гиблый, то хорошие программисты не помогут, а если тренд офигенен, то и плохие вряд ли навредят. Даже если и влияют.

Как-бы Вам сказать попроще. Если машина, при наличии хорошего двигателя, не едет по причине поломки коробки передач из этого не следует делать вывод, что двигатель не нужен и на бизнес не влияет. Для того, чтоб машина ехала нужен И двигатель, И коробка передач, И еще дофига чего. Не OR , а именно AND. Вот где-то так.
А на счет заменяемости. ну так незаменимых людей почти нет. Но и лошадей на переправе менять, как минимум не разумно, хотя теоретически возможно.

ЗЫ но вброс нече так 🙂

Vladimir Prokopchuk Team Lead в IBM 15.07.2011 16:35

Не совсем корректное сравнение. Если брать сравнение IT с автомобилем, то двигатель — это R&D отдел в целом, а программисты — это машинное масло 😉
Ведёт это всё водитель (топ-менеджмент), менять которого тоже можно, но очень осторожно.

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

Andrii Mishkovskyi Software Engineer в FreshBooks 15.07.2011 17:02

Неправильно. Программист — это собака, а R&D отдел в целом это пылесос, а ведет это всё дедушка Ленин (топ-менеджмент). Тем временем в Антарктиде пингвины, ради которых всё это и затеяно.

Sincerely yours, Misleading Analogy.

Oleg Shanyuk imagination extension в obrij 15.07.2011 17:30

Я считаю, что программист это автомобильный бог-невидимка, R&D — в таком авто отсутствует, топ-менеджмент — это приборная панель, руль крутит водила хозяина, который в лучшем случае когда-то знал, что такое разработка ПО, но позабыл это как страшный сон. Сам хозяин на машине не ездит — у него автопарк таких такси.

Следите за шашечками

Так тут в основном про шашечки 🙂

Вспоминаем про периодичность смены масла 🙂

Если проект не может работать без программистов, что же они тогда запрограммировали?

Видите ли чтобы проект существовал нужно чтоб его таки кто-то напрограмировал. Ну не может построится дом без строителей. Не может и все тут, хоть тресни.
ЗЫ вы прямо-таки заставляете меня отбирать работу у КО.

Машина без автомеханика — тоже относительно недолго ездит 🙂

Я бы предложил такую аксиому.

Не влияют только в том случае, если команда молча и последовательно выполняет все поставленные задачи. То-есть можно сказать, что команда представляет собой инструмент, не имея возможности проявить свою волю. А к инструменту какие притензии? Вся ответственность на том, кто им орудует.

Но как бы такого почти никогда не бывает. Поэтому влияние всегда есть в той или иной степени.

23х-летние синьоры — не влияют. и 23х-летние джуниоры — тоже, как бы ни обидно им было. Больше того — нет никакой «лажи», которую они бы могли сотворить — и которую невозможно было бы прикрыть на более высоком уровне.
С другой стороны — бизнес-аналитики, проджект-менеджеры и архитекторы — да, влияют.

Т.е. где-то есть «уровень влияния», до которого люди заменимы без проблем, а после — не очень.

Eugene Poponin Чувак на котором всё держится в 908 15.07.2011 14:24

Кадры решают все, кажется это сказал Сталин

Потом он подумал и добавил, нет человека, нет проблем.

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

Не знаю стоит ли высказвания тирана воспринимать как руководство к действию, но вот пару цитат:

— Есть человек — есть проблема
— Незаменимых людей у нас нет

— Если у человека много проблем, он сам становится проблемой

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

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

А Гитлер был художником и вегетарианцем. Но мы же не будем делать из этого многозначительных выводов, верно?

Max Yehorov Software Engineer 15.07.2011 14:08

Mike Gorchak Graphics Device Driver Developer в QNX Software Systems 15.07.2011 13:40