Разница в мышлении бизнеса и программиста. Типичные ошибки с обеих сторон и как их исправить?
Бизнес держит в голове деньги, сроки, фичи, качество. Программисты — долговременное качество кода, поддерживаемость, актуальность.
— Я плачу вам деньги, а вы должны работать так же, как я сам © бизнес
— Я пишу код, а вы должны обо мне заботиться © программист
— Если нужно сделать к сроку — значит нужно сделать к сроку © бизнес
— Говнокод писать не буду. И эстимейтов тоже не дам © программист
Вроде всем всё понятно, и никто ни о чем не спорит. А потом приходит нежданчик, обычно в виде «классный код написали, а теперь удалите его» от бизнеса и «эта задача заняла больше времени по объективным причинам» от программистов.
Какие ошибки совершили обе стороны, и что можно сделать лучше?
Чужая проблема
Что думает заказчик? «Я им плачу зарплату, свою часть договора выполняю. Пусть они просто выполняют свою. Договор — это важно, вся жизнь выстроена на договорах». Программисты думают: «я пишу код, а для планирования — есть заказчик (бизнес) и менеджеры. Как можно ждать от меня четкого эстимейта, если я эту задачу еще не делал? Если надо, могу рассказать подробно, что может пойти не так — ТЗ, третьесторонние библиотеки, интеграция и т. д.». Что думают менеджеры — обычно зависит от того, откуда они пришли в менеджмент. Если из программистов — то как программисты, если от бизнеса — то как бизнес... Про игры с компенсацией и компенсацией компенсации сегодня не будем.
На размышления еще здорово влияет рынок труда — про «рынок перегрет, программисты зажрались» все слышали. Когда кругом тебя райский сад в виде долларовой зарплаты, а под боком — война, то заокеанские проблемы с запуском стартапа сложно воспринимать всерьез.
Если программисты думают, что это проблема исключительно заказчика, то бизнес рано или поздно заканчивается, приходится срочно и внезапно искать новую работу, да и резюме портится.
Если заказчик думает, что это проблема исключительно программиста — рано или поздно все активные уходят, а остаются пофигисты и нытики.
Что делать?
- Думать, что именно я могу сделать для решения проблемы другой стороны.
- Это прибавляет не только головняк, но и visibility. Что в свою очередь ведет к росту зп и звания.
- Именно я, а не начальник, заказчик и т. д. Переложить ответственность на
МВФдругих очень просто и очень плохо.
- Не вешать на себя ответственность за то, на что не могу повлиять. Если провтык в маркетинге, то, скорее всего, это за моей областью знаний. Если я придумаю что-то — круто! Если нет — ну ок. Граница между «что я могу сделать?» и «это не моя зона ответственности» очень тонка и уходит в освоение смежных областей.
Пара слов про «узкий специалист» vs. «широкий профиль». Давайте сравним двух условно одинаковых людей, с одинаково развитой памятью, IQ, умением учиться, силой воли и т. д. Узкая специализация даст плюсы при работе в большой организации, широкий профиль — при работе в стартапе или на топовых позициях. Узкая специализация позволит найти лучшую работу, широкая — найти работу быстро. Как пример — можно быть спецом по Коболу. Если есть такая вакансия — возьмут за любые деньги. Если нет — можно ждать вакансии годами.
Круг общения
Свойство у человека — мерять всех по своему кругу общения и думать, что все остальные +/- такие, как ты. Если кругом все программисты — думаешь, как программист: фреймворки, исследования, хитрые глюки, гаджеты и т. д. Если кругом безработные — думаешь, какой пипец на рынке труда происходит и как это несправедливо. Если кругом бизнесмены — от всех кругом ждешь проактивности, умения быстро учиться и решать самые неожиданные проблемы. Если кругом все депутаты
Для бизнеса многие действия программистов выглядят чушью — достаточно просто сказать, поговорить, быть более настойчивым, сделать стратегическое планирование. И в своем кругу они время от времени это обсуждают — «ну какого ты мне не сказал, что не успеваешь? Я бы отменил презентацию, это дешевле, чем провалиться, показывая лежащий сайт».
Для программистов многие действия бизнеса выглядят чушью — достаточно следовать КЗоТу, арендовать нормальный офис, нанять девопса и офис-менеджера. И само собой нужно платить зарплату, как в LA.
Что делать?
- Понимать, как выглядит ситуация с другой стороны. Для этого — больше общаться, затрагивая нерабочие темы: детей, политику, путешествия, культурные отличия. Меньше говорить, больше слушать. Последнее для многих сложно реализовать, так как говорить приятнее.
Личный контакт
Если нет личного контакта, то другая сторона превращается в юнитов компьютерной игры. Их легко обманывать, их интересы можно игнорировать, да и пожертвовать ими тоже легко. «Ну развалится его бизнес — а нефиг было лезть, не зная броду» и «выйдут на выходных — нефиг было косячить».
Что делать?
- Менеджерам: помогайте видеть людей, а не юнитов!
- Программистам: почаще общайтесь с бизнесом. Перейдите из «еще один безликий программист в зарплатной ведомости» в «это Вася, мы с ним составление отчетов обсуждали. Толковый конструктивный парень».
Разная детализация
Что видит капитан? Штурвал, острова на горизонте, макушку гребца. Бизнес видит KPI, ROI, инвестиции, стратегическое видение, переговоры, конкурентов, бюджет и макушку программиста. Если он начнет уделять всё своё время вниканию в задачи и проблемы программиста — он сдохнет. Времени на всё не хватит, бизнес и так обычно живет в диком ритме. Поэтому как в шутерах — железо не тянет? Снижаем детализацию!
Что видит гребец? Весло, чуть-чуть штурвал, иногда — капитана по пояс. Снизу. В смысле — фреймворки, криво написанные задачи в тасктрекере, тормозящий комп, любимыесовещания, иногда — совещания с заказчиком на непонятном языке: мало того, что английский, так еще и бизнес-терминология. Программист концентрируется на мелочах и мельчайших подробностях. Чем выше детализация — тем меньше багов.
Сверху не видны мелкие детали, снизу видны только мелкие детали.
Попытка увидеть на другом уровне — трудоемка. Ну то есть хорошо бы, но «пиши код!» — так что только в свободное от работы время.
Менеджеры не видят ни деталей, ни больших целей одновременно. Менеджеры просто быстро переключаются. Кстати, менеджеров в кризис увольняют первыми, и это еще одна совсем другая история.
Что делать?
- Балансировать и нырять туда-сюда. Смотрите на ситуацию со всех точек зрения. Предугадывайте реакцию обеих сторон.
- Не ждать, что бизнес поймет очевидные вещи без детальных объяснений. «А почему нельзя просто скопипастить этот модуль? Зачем тратить время на написание общего класса?»
Конфликт ценностей
Что думает бизнес?
Что думает программист?
Ну-у-у... Так, наверное, бывает... В сказках... В этих сказках еще толковое ТЗ и идеальный процесс разработки... Всё-таки установка «эта работа — самое важное в моей жизни» чаще бывает у собственников. Или у тех, кто сильно влияет на ход проекта. Долгую историю про то, как эджайл дает такое ощущение — тоже отложим на потом. А пока — для программистов работа — это инструмент для зарабатывания денег и кучи других мотивационных штук. И очень редко «этот проект — самое важное для меня».
Что делать?
- Знайте, что важно для другой стороны. Максимальная эффективность? Бог? Деньги? Семья? Если у вас для всех получается один ответ, значит, что-то не так. Люди разные.
- Уважайте чужие ценности и требуйте уважения к своим. Чужие ценности не нужно принимать, их достаточно уважать. «Ты веруешь, а я атеист. Ок, я не смеюсь над купанием в проруби, а ты не проповедуй мне без моего запроса».
- Уважение к чужим ценностям имеет ограничение — если для другого важно «я отжимаю, что хочу», то я это уважать не буду. Правила для сотрудничества и правила для войны разные. Можно перечитать про овертаймы.
Вместо выводов
Этот сайт для программистов, поэтому выжимка из статьи тоже только для программистов.
- «Какую проблему бизнеса я могу решить?»
- Общайтесь с бизнесом больше.
- Бизнесу некогда вникать в детали.
- Если сможете его от этого избавить — будет хорошо.
- Если сможете говорить на его уровне детализации — будет еще лучше.
- У бизнеса — другие ценности. Уважайте их и требуйте уважения к своим.