Comments 35
Хорош уже шлифовать мозги одной и той же мантрой. Разработчик должен то, это... За всех подумать, погрузиться в бизнес (при полном отсутствии возможности принчтия финансовых решений... Например, я как разработчик, погрузившийся в бизнес хочу выписать себе премию. Я много работал. Никто таких полномочий разработчику не предоставит). Составить презентации, написать план и обосновать затраты розовощеким менеджерам. И сделать ещё свою работу. Ничего не треснет? Бизнес, особенно средний и крупный - это жернова перемалывающие всех. Цель одна - прибыль. Люди - ресурс. Все. Каждый должен заниматься своим делом. У Крылова есть басня Щука и кот.
Здравствуйте! Для начала хочу отметить, что я не писал, что разработчик должен что-то. Не знаю откуда вы это взяли. И не писал, что надо делать чужую работу. Наоборот, дело в командной работе. В совместной работе. Чтобы все участники команды понимали все цели и приоритеты одинаково. Ну и много чего другого это дает, проще коммуникация становится и межкомандное понимание, и т.д. в статье описаны разные моменты.
Не уверен, что адаптация уже существующего сервиса под требования n+1 страны это настолько интересная для разработчиков задача, чтобы они прямо горели. Самая рутинная рутина.
Тогда справедливо требовать от менеджера немного вникнуть в типы баз данных и типы репликации. Возможно еще немного почитать про кубернейтс и типы Амазон инстансов. Ведь тогда он будет лучше понимать и оценивать сроки и сможет более оптимально тратить бюджет. И коммуникация лучше будет с командой программистов
Спасибо за комментарий! Да, я полностью согласен. Погружение будет лучше, если оно будет в две стороны. Я приветствую, когда инициатива исходит от коллег. Но если её не хватает, то можно прикладывать свои усилия, чтобы это произошло. Только я бы не стал использовать слово "требовать". Моя статья не про требования в целом, и не про противостояние. А про то, что может же нам, разработчикам помочь в работе. Особенно это касается продуктовой разработке. Конечно, в проектной и аутсорсной дела могут обстоять немного иначе. А так, я с вами согласен.
А куда отписаться по сломанной денежной транзакции? Я получил ошибку при заказе на пол секунды при оплате и возврат денег. Но заказ улетел на кухню, о чем я не знал и сделал повтор.
В АйТи отдел писать, там починят
Привет! В саппорт, я думаю, можно отписаться. Там обычно помогают ;) В разделе Контакты и там кнопка "Написать".
Ну не знаю, как-то сложно замотивироваться и проникнуться бизнесом в микропродукте (я имею ввиду с точки зрения разнообразия бизнеслогики). Ладно когда вас трое кодит, при этом каждый оунер, но в додо программистов больше чем поваров. Сеньер шоппинг карт сабмит батон лид девелопер?
Спасибо за коммент! В Додо программистов меньше, чем поваров
Я согласен, что у всех устроено по-разному, и сравнивать компании и процессы вот так напрямую не всегда получается. Я описал, как это работает у нас.
Сеньер шоппинг карт сабмит батон лид девелопер?
Нет, таких у нас нет пока Мобильных разработчиков, например, не так много. И у каждой команды есть понятные цели, как они влияют на продукт.
Стройте свою компанию и там сами решайте, какие задачи вам сегодня делать, а какие - нет. Все просто.
Всё так. Но это не противоречит тому, что написано в статье.
Например, если кто не хочет стоить свою компанию, а хочет присоединится к уже существующей компании и расти вместе с ней, то статья именно для этого случая. Я не говорю, что можно прийти в любую компанию и начать говорить, что сейчас я буду выбирать себе задачи Статья вообще не про то, чтобы выбирать себе задачи, а про погруженность разработчиков с бизнес, про процессы, про мотивацию.
Я люблю погружаться в бизнес домен, это дает некоторое ощущение власти, когда ты лучше менеджера знаешь его цифры, да еще видишь где он их, скажем так, приукрашивает.
Класс! А как у вас это устроено? Ты сам погружаешься как-то или у вас процессы какие-то есть для этого?
сам погружаешся, т.к. если тебе надо написать расчет какого-то kpi - ты полюбому должен знать как он считается. Причем и для всех пограничных и вырожденных случаев, про которые и бизнес-оунеры не думали никогда
Это забавно всё, только вы ща описываете какихто 1Сников… и власть ты типа ощущаешь, а зарплата у тебя черти какая
партнёрские отношения внутри компании - это когда ваша доля в прибыли прописана в уставе компании и может быть продана или унаследована вашими детьми. в крайнем случае - когда доля в прибыли прописана в трудовом договоре. если руководство говорит о партнёрских отношениях, но не готово ни на один из этих шагов, мы имеем обычную манипуляцию.
партнёрские отношения внутри компании - это когда ваша доля в прибыли прописана в уставе компании
Это обычно называется опционная программа. Она кстати, становиться всё более популярной в ИТ в России. Не так, еще конечно, как на западе. Но, мне кажется, у вас в этом направлении идет движение. Это как раз то, о чем вы говорите. И это крутая штука!
Но в статье я писал не про товарно-денежные отношения (они важны, конечно, и это отдельная тема), а про процессы в работе, про мотивацию, как сделать так, чтобы я работал эффективнее и мне это приносило удовольствие.
Когда один партнер предоставляет свои знания и время, а другой - рабочее место и деньги - это тоже партнёрские отношения.
>А можно разработчик сам будет решать, какие задачи ему делать?
Да запросто. Коля хочет рефакторинг, Вася желает кнопку перекрасит в зелёный, а Петя ту же кнопку хочет покрасить в красный. Коля, кроме всего прочего, верит в плоскую землю и хочет переписать всю логистику с учетом этого. Ну как, позволим им решать что делать?
Про плоскую землю не просто так написал. Часто представление о том как бизнес работает примерно на этом уровне находится. Никогда не сталкивались - «сволочи, тут материала на 10 коп. а продают за 100 руб.» Налоги, логистику, конкурентов, риски и прочее никто не учитывает и не умеет. Программистам простительно, это не из иепархия. Но когда они с этими пещерными знаниями начинают решать, что им делать, чтобы двигать бизнес вперёд, то жди беды.
А ещё у каждого члена команды своё видение того, что правильно. В итоге будет как у всех, только с другим соусом. «Доверие это наша ценность, поэтому мы доверяем нашим руководителям и делаем как они просят. А если у появляются идеи от команды, то 99% мы выкидываем, а 1% адекватных делаем. Опять же, так решил руководитель, которому априори доверяем».
Даже в вашем примере - команда решила и сделала баннер. Wow, вот это прямо та фича, которая dodo будет кормить следующие 10 лет. Такие мелкие улучшения делаются везде и без Agile, ценностей и особенной корпоративной культуры.
Спасибо за комментарий! Смотри, если вы прочитали статью, то наверное вы не будете утверждать, что разработчик решает, какие ему задачи делать, в прямом смысле слова. Эта статья про погруженность разработчика в бизнес. Про то, чтобы видеть компанию "глазами первых лиц". Про Technical Excellence. Про большинство Agile принципов, которые описали не самые глупые люди индустрии, мягко говоря. Я не скрою, заголовок у статьи немного провокационный. Но статья не про это.
Это статья не про то, чтобы спрашивать разработчика, что нам сделать. Не про принятие просто так задач в беклог. Ни про что из того, что вы описали в комментарии. Я без каких либо претензий, или наездов, просто мне кажется вы не до конца поняли суть статьи.
Последний комментарий про Wow фичу и кормить 10 лет - я тоже не понял, откуда эти оценки взялись. Это один из примеров в статье. Во-первых, да, это не большая фича, никто не спорит. Но во-вторых, она дает реальную пользу, выраженную в деньгах. Потому что запуск франшизы в новой стране охватывает все бизнес процессы компании, где экономия и оптимизация процессов очень важна и оценивается в деньгах.
P.S. Купите Коле книжку по физике :)
Ребят, а сделайте пожалуйста выбор языка. Приезжаешь в другую страну, переключаешь приложение на новую страну, а языка не знаешь.
Статья классная, спасибо большое!
Вы писали о погружении
...нам надо немного погрузиться в то, чем они занимаются, и станет понятно, зачем мы делаем наши задачи. Погружаться можно совсем немного, но этого может быть вполне достаточно, чтобы всё стало так же как и с пет-проектом
Здесь не совсем согласен. Более-менее серьезные Android-проекты имеют столько классов, столько кода, что погрузиться во все - займет уйму времени. Такое погружение произойдет со временем, но будет очень поверхностным.
Через год-два работы в проекте может и удастся во многое вникнуть, но так, чтобы "сейчас сяду и разберусь тут во всём, чтобы понимать, как оно работает под капотом" - вряд ли удастся (особенно в андроид), хотя очень хотелось бы(
Пет-проект сделан своими руками. Проект компании сделан десятками других людей. Погружение в задачи сотрудников требует массу умственных сил - и всё это помимо ваших основных текущих задач.
К сожалению, иногда придется воспринимать часть логики как некий Черный Ящик А, который вернет B для моего класса C.
Привет! Ты всё правильно говоришь. Но это некий базовый сценарий. Где не надо даже стараться. То что я описывал в статье, это когда и разработчики и бизнес идут обоюдно на встречу друг другу.
В этом случае, говоря простым языком, и разработчик будет чаще предлагать более правильные бизнесовые задачи, и бизнес будет более внимательно слушать разработчиков.
Работник работает лучше когда полагает, что решение поработать он принял по собственной инициативе. Погруженность в бизнес, чувство ответственности или вины, решение сложной нетривиальной задачи, срочность - этих сеттингов куча.
В простонародье это называется «авторитет». И этим авторитетом вполне можно задавить бизнес (сделать то, что хочется, как Вы говорите). И нет никаких «принципов», «ценностей», «technical excellence», «mvp» и прочей мишуры. :)
ps Кстати, у меня для Вас не очень хорошая новость: для этого нужен определенный типаж людей. Вы никак и ничем не заставите погружаться в бизнес человека, который кроме кодинга/архитектур ничем другим заниматься не хочет. Душа не лежит. Имеет право. Просеивайте на собеседовании, если нужно. Иначе, imho, почти никак.
Будьте предпринимателями.
Вот-вот, это как раз оно: такой же бесполезный призыв, как «будьте богатыми!». Призыв крутой, но совершенно нерабочий.
Круто! Спасибо, что поделились вашим опытом! Я тоже делюсь опытом.
И этим авторитетом вполне можно задавить бизнес (сделать то, что хочется, как Вы говорите)
Моя мысль сводится к тому, что при тесной работе, о которой я говорю, не будет такого "что нам хочется" или "что им хочется". Нам должно в итоге хотеться одного и того же. Ну это как модель, к которой можно стремиться.
И нет никаких «принципов», «ценностей», «technical excellence», «mvp» и прочей мишуры. :)
Только лишь одного авторитета не достаточно. Потому что просто задавив авторитетом, и не обязательно делать эффективные и классные штуки. Скорее всего в вашем случае были просто золотые и супер классные сотрудники и коллеги, которые в купе с авторитетом создавали классный продукт!
Кстати, у меня для Вас не очень хорошая новость: для этого нужен определенный типаж людей.
Полностью согласен! Мы стараемся проводить тщательные собеседования, уделяя много внимания софт скилам, которые нам важны.
Вот-вот, это как раз оно: такой же бесполезный призыв, как «будьте богатыми!».
Почему он бесполезный? Вы можете приводить в пример людей, которые совершенно этого не хотят, им это чуждо, некомфортно и т.д. Ок, нет проблем с этим. Но есть много людей, у которые есть в этом потенциал, но они не раскрывались в этом. Под предпринимательским подходом я понимал больше ответственность и вовлеченность в процесс.
А можно разработчик сам будет решать, какие задачи ему делать?