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

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

Наёмный работник тем и отличается от стартапера, что у него есть лишь обязанности, за которые он получает зп

Мы с коллегами разошлись во мнениях, есть товарищи, которые свято верят в то, что смогут найти разработчика с антрепренерскими скиллами

Если говорить в понятиях "Member of the board" и "Управляющий партнёр" - то разработчиков там никаких нет, просто приглашается партнёр, при этом он может обладать любым профессиональным бэкграундом, а может просто кофе клиентам готовить и за жизнь говорить.

Есть интересный вариант совмещения Product owner с предпринимателем - что твой "own" выходит за пределы формальных спринтов, и тебе сам продукт как предпринимателю предлагается развивать. Вы про похожий сценарий, или, всё-таки, про классический найм на позицию?

Мы с коллегами разошлись во мнениях, есть товарищи, которые свято верят в то, что смогут найти разработчика с антрепренерскими скиллами

Не вопрос, у меня есть, но дорого.

Свой стартап делал (фейл), переговоры вёл, решения принимал, людей нанимал. Вопрос в том, правда ли это подходит под определение разработчика )))

В бизнесе тоже ориентируюсь как правило более-менее

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

Вот что примерно у вас получается В договоре написано "в общем смысле требуется развивать продукт самостоятельно"

🙀

Если полностью самостоятельно могу развивать продукт - зачем мне работать разработчиком? Я буду исполнительным/генеральным ))))

Бинго

Либо будешь кофаундером где-нибудь :)

Я думаю имеется ввиду что я должен укладываться в какую-то глобальную стратегию развития, а за тактику отвечать сам

Либо будешь кофаундером где-нибудь :)

Собственно у меня так и было ))

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

Как-то сложно формулируете

Я про укладываться в какую-то глобальную стратегию

Чтобы в нее укладываться нужно понимать рамки, которые она определила

А не скиллы иметь

Ну видимо имеется ввиду что есть какой-то генеральный, который говорит куда мы идём в долгосрочной перспективе

Скиллы тоже, но не скиллы разработчика

А что-то вроде СТО

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

Моё предпоследнее место - на разработку оставалось что-то типа 10% времени

Зависит от размера компании

И от задач наверное. В общем в идеальном мире можно придумать расклад когда потребность пользователя очевидна всем, в том числе дворовой собаке, поэтому один фуллстэк-разработчик может сделать всё. Причём потребность настолько сильна что на дизайн поначалу можно забить. Вот только что-т мне не верится что такие области ещё существуют )

Дизайн это вампир

Но который умудряется пить кровь даже если его нет

https://www.tesla.com/no_NO/careers/job/regional-hrbusinesspartner-salesservice-48213?redirect=no&no_cache=1493276918

Я работал на американцев, и там был опцион. И там я развивал продукт, будучи техлидом. В текущем проекте сложно найти даже ЛПР

А есть кто-нибудь из Digital-агенств кто пробует гибкие подходы (или хочет попробовать)? У меня есть пошаговая инструкция, которая раскрывает некоторые аспекеты Kanban, возможно вам будет интересно ознакомиться. Напишите в приват.

http://bit.ly/2pmJvT1 про это?)

Я работал на американцев, и там был опцион. И там я развивал продукт, будучи техлидом. В текущем проекте сложно найти даже ЛПР

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

Да, как?

Есть там всякие т образные люди)))

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

Фон чату можно добавить?

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

Это вопрос менеджмента и мотивации, а не просто "дать опцион". Пожалуй, лучше Спольски тут не скажешь: http://local.joelonsoftware.com/wiki/%D0%9C%D0%B5%D1%82%D0%BE%D0%B4_%D1%8D%D0%BA%D0%BE%D0%BD%D0%BE%D0%BC%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B9_%D0%BC%D0%BE%D1%82%D0%B8%D0%B2%D0%B0%D1%86%D0%B8%D0%B8

Да, как?

Нормально, но пока не похоже на Step-by-Step. В том числе, неясно - как прозрачно определить срочность и проиритет в целом.

Как развивать продукт, будучи разработчиком, Денис?

)) За фибдек - спасибо

Слава, ты сейчас кому вопрос адресовал? :) Боровикову или мне?

Сон вот что помогает разработчикам развивать продукты :)

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

facebook как акт самоутверждения

и github

*giggle*

берется неделя на анализ деятельности определенной позиции (аккаунт-менеджер, сейлз, саппорт), товарищ работает в обычном режиме, рядом сидит разработчик и смотрит, какие бизнес-процессы можно автоматизировать, далее идет совместное ревью с приоритезацией

берется неделя на анализ деятельности определенной позиции (аккаунт-менеджер, сейлз, саппорт), товарищ работает в обычном режиме, рядом сидит разработчик и смотрит, какие бизнес-процессы можно автоматизировать, далее идет совместное ревью с приоритезацией

Это не развитее непосредственно продукта, а внутреняя разработка внутренних тулов, это понятно.

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

Надевать шкуру потребителя это наверное единственный мощный способ делать что-то нормально :)

бизнес и есть продукт для этой компании, ибо там 100% консалтанс

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

от процента автоматизации зависит скейл, для бизнеса важен time to market

все готовое обычно требует допила

у каждой конторы свой бизнес процесс

бейзкамп так развивал свой продукт

сделали хорошо и гибко для себя, затем продали

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

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

букингдотком работает с овнершипом разработчиков с самого начала

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

как, к примеру, salesforce из коробки смоделирует бизнес?

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

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

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

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

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

да, деньги вернули, но время ушло, а с ним и часть рынка

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

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

почему в такой компании ключевым оказалось держать руку на пульсе финансовых потоков?

почему?

можно было бы нанять в кажлой стране по конторе и после пытаться отстроить решения по расчету пластиком - это скейл?

и как они их заутсорсили?

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

тут конечно сплошные владельцы уберов сидят в этом чате =) начинающей компании все это не надо

аутсорс это зависимость, которую практически не контроллируешь

да, аутсорсить типовые, одинаковые для всех процессы - это нормальная практика

я таких клевых аутсорсеров встречал, счастлив что они код писали, а не свои :))