, как бы о том что "компании продукт продать не получилось, видимых преимуществ нет, а обещаемые будут неизвестно когда". Мой — компания купила сильную идею и очень сильную да ещё и охрененно само-мотивированную техническую команду, но профукала менеджмент.
Менеджера у нас практически не было (только в самом начале). Но проблема тут еще и в том, что не расширяя команды толку от этого мепнеджмента не было. Что делать в коде мы и так знали наперед. А для остального у нас уже не было ресурсов. В проекте много исследовательской составляющей. Понять за сколько можно произвести исследование и найти нужный путь практически невозможно. Я думал мы создадим алгоритм восстановления за месяц, а на это ушел год (если не больше).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>А вот создать кроссплатформенный бэкэнд, который работая под дотнет (ил Моно) будет порождать бинарники для JVM или LLVM — это не проблема. И тут несколько месяцев на фул тайме более чем достаточно.
Насколько я понимаю MSIL у вас сейчас получить можно. Unity развивает доморощенную MSIL 2 CPP, соединив которые технически можно код на любом недекларативном языке с описанием транслировать в С++. Это может быть интересно Unity, поскольку открывает им легкий путь поддержки БОЛЬШОГО числа языков. но и сама идея N + MSIL2CPP для получения С++ кода кажется коммерчески нужной. Без привязки к Unity. Расширяемость языка трудно продать даже таким китам как М. Одердски поэтому что говорить об остальных. Более того, расширяемость действительна интересна в экспертных системах (обработки знаний), где понятия естественного языка прямо проецировались и компилировались в понятия и правила (программные узлы, связи) целевой системы. Для ускорения анализа. Возможно это натолкнет вас на какие мысли.
Здравствуйте, VladD2, Вы писали:
VD>В виду того что Нитра рассчитана на языки с динамически расширяемым синтаксисом мы не могли переиспользовать части РаШарпера (ну, кроме его ГУЯ и сервисов в IDE). По идее наш движок мог бы стать новым поколение движка для РеШарпера и очень сильно улучшить его. Но это серьезное решение на полную переделку базы. ПМ-ы решарпера не готовы к столь радикальному изменению.
История знает очень мало успешных историй с полной переделкой. Почти все такие полные переделки дохнут, предварительно сжирая время, доверие и конские бюджеты.
Здравствуйте, Ikemefula, Вы писали:
I>История знает очень мало успешных историй с полной переделкой. Почти все такие полные переделки дохнут, предварительно сжирая время, доверие и конские бюджеты.
Ага. Так бы самолеты на пропеллерах и летали бы...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hi_octane, Вы писали:
КТ>>Jetbrains. В первую очередь Нитру надо было продать Jetbrains'у. _>Так это шаровара была? Потому что во всех остальных случаях пишут одни а продают другие...
Продавать = доносить свои решения до руководства. Нужно поддерживать интерес руководства, демонстрировать профит, прогресс, возможности. Для этого нужно самому в первую очередь планировать свою работу определенным образом. То есть, начать революцию с себя, а не с менеджеров Джетбрейнса. Влад наверное думал, что менеджмент будет сидеть сутками на RSDN и читать местные форумы.
Расскажи, как продавать эту нитру ? Посмотри, чего в родмапе, вот список профитов за все майлстоны:
Express language grammar in a concise form, without heavy-lifting on complexities of EBNF and such.
Generate fast parser and PT builder
Implement semantic analisis (typing) engine.
Implement IDE support for Nitra powered languages.
Implement IDE support for Nitra
Implement Extensible C# and Nemerle 2.0 on Nitra
Make Nitra independent from Nemerle 1.0.
Move Nitra on .Net backend and Nemerle 2.0.
Release Nitra 1.0 (make distributive and deploying nuget packages)
Типичный менеджер от этого списка придет в ужас. Единственное, чем можно заинтересовать, это Extensible C#, на который ушло три года и которого еще ждать неизвестно сколько. Кром того, этот вариант уже доступен другим способом — чз Roslyn. То есть, в кратце, в родмапе нет ничего, что хотя бы намекает на осязаемую пользу.
До кучи, из родмапа следует, что цель Нитры — это Немерле. Это не просто непонятно, это вводит в заблуждение. Крутость Немерле пока что следует из рассказов Влада, что во второй де версии будет ого-го, а для второй нужна Нитра. Вот и получается парадокс — для крутости Немерле нужна Нитра. А Нитре для крутости нужен Немерле
Нужны не трёхчасовые презентации раз в три года, а постоянные демонстрации хоть чего то полезного. Пусть это работает долго и коряво, зато можно потрогать и пощупать. Собтсвенно приседания с IDE нужны в последнюю очередь — индустрия десятками лет спокойно хавает всевозможные препроцессоры.
Кроме того, языки программирования сами по себе не летают. С момента выпуска проходит много времени, прежде чем начнется собственно сама монетизация. Потому фремворк изготовления языков в перспективе рискует окупиться лет через десять.
Как я вижу, Нитре мешают амбиции Влада со-товарищи. Они продолжают идею расширения и всемогуторства, грамматики и анализаторы. Между тем адски востребованы всевозможные кастрированые версии языков и инструменты для построения таких вещей. Пример — xml-html-шаблоны всех сортов. В каждом из них используется какой нибудь особый язык для байндинга.
Примерно так
Загрузил грамматику, отметил мышом, какие фичи должны быть недоступны в дсл
Загрузил грамматику второго языка
накидал примерный вариант странички
тул показывает конфликты, косяки и тд и тд
когда конфликты устранены, на выходе получается готовый препроцессор, который можно на раз прикрутить к любой IDE, как это сделано с ангулярами всех версий, jsx, razor и прочими вещами.
То есть, предоставлять разрабу возможность работать со знакомыми ему языкjм, а не вынуждать его погружаться в парсеры-грамматики и прочие дебри-немерли.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Ikemefula, Вы писали:
I>>История знает очень мало успешных историй с полной переделкой. Почти все такие полные переделки дохнут, предварительно сжирая время, доверие и конские бюджеты.
VD>Ага. Ток бы самолеты на пропеллерах и летали бы...
Намекаешь, что тебе надо столько же времени ?
С самолетами ровно то же, о чем я и говорю — с появлением самолёта никто не кинулся начисто переформатировать бизнес/армию с нуля. Они стали всего лишь еще одним транспортным средством. С момента изобретения до внятного применения прошли путь длительностью примерно 50 лет.
Здравствуйте, VladD2, Вы писали:
КТ>>Для перевода Нитры на какую платформу? JVM? LLVM? Пару месяцев для одного программиста? Или все же для нескольких?
VD>Перевести всю Нитру на другую платформу будет не просто. Для этого сначала на нитре надо переписать Немерл и забутстрапить с ним саму Нитру.
Вот с этого момента и можно начинать думать как же уломать менеджеров. То есть, на нынешний момент непонятно сколько работы для завершения, непонятно сколько времени на Немерл, непонятно сколько времени на буцтрап и тд и тд. Вобщем решение менеджмента очень даже понятно.
Здравствуйте, Ikemefula, Вы писали:
I>Намекаешь, что тебе надо столько же времени ?
Я не намекаю, а открыто говорю, что в реальной жизни есть такая штука как прогресс. Никому в голову не придет совершенствовать одну и ту же модель самолета всю жизнь и отказываться от разработки новых на основании каких-то предрассудков. Появляются новые технологии. Они находят отражение в новых подходах. Создаются новые самолеты (автомобили, поезда, программы).
I>С самолетами ровно то же,
Что "тоже самое"? Все самолеты являются эволюционным развитием этажерки братьев Райт?
I>о чем я и говорю
Говоришь много, но не по делу.
I>- с появлением самолёта никто не кинулся начисто переформатировать бизнес/армию с нуля.
С появлением самолетов каждая фирма/конструктор делала свой новый самолет. От самолета братьев Райт в них только общая идея наличия крыльев и хвоста осталась.
Появляются новые знания и они воплощаются в новых самолетах.
I>Они стали всего лишь еще одним транспортным средством. С момента изобретения до внятного применения прошли путь длительностью примерно 50 лет.
Ну, ты не боись. Нитра — это тоже "всего лишь еще один" тул для создания языков. Только создаваемый с учетом всех современных наработок в этой области. Для этого его приходится создавать с нуля. Точно так же как для создания реактивных самолетов пришлось делать новый самолет, а не впихивать реактивный двигатель в этажерки.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ikemefula, Вы писали:
I>Вот с этого момента и можно начинать думать как же уломать менеджеров. То есть, на нынешний момент непонятно сколько работы для завершения, непонятно сколько времени на Немерл, непонятно сколько времени на буцтрап и тд и тд. Вобщем решение менеджмента очень даже понятно.
Делай, что должен и будь, что будет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Я не намекаю, а открыто говорю, что в реальной жизни есть такая штука как прогресс. Никому в голову не придет совершенствовать одну и ту же модель самолета всю жизнь и отказываться от разработки новых на основании каких-то предрассудков. Появляются новые технологии. Они находят отражение в новых подходах. Создаются новые самолеты (автомобили, поезда, программы).
Создаются. Только не за счет отказа от старых работающих денежных проектов. бОльшей части контингента тот же Решарпер не нужен целиком. Как бы ты ни усиливал решарпер, совсем не факт, что фичи удастся монетизировать.
VD>Что "тоже самое"? Все самолеты являются эволюционным развитием этажерки братьев Райт?
Ради самолетов никто не резал работающий, отлаженый и денежный бизнес. А ты предлагаешь именно это — перепилить решарпер тот же.
VD>Ну, ты не боись. Нитра — это тоже "всего лишь еще один" тул для создания языков. Только создаваемый с учетом всех современных наработок в этой области. Для этого его приходится создавать с нуля. Точно так же как для создания реактивных самолетов пришлось делать новый самолет, а не впихивать реактивный двигатель в этажерки.
Это никому, кроме тебя, не интересно. Решарпер тебе не дадут перепилить, пока он приносит деньги.
Здравствуйте, VladD2, Вы писали:
I>>Вот с этого момента и можно начинать думать как же уломать менеджеров. То есть, на нынешний момент непонятно сколько работы для завершения, непонятно сколько времени на Немерл, непонятно сколько времени на буцтрап и тд и тд. Вобщем решение менеджмента очень даже понятно.
VD>Делай, что должен и будь, что будет.
Ага, хочешь инвестиций — учись играть по правилам того бизнеса, у которого берёшь деньги. Других вариантов нет. Бизнес за идею не работает.
Ты всю ветку почитай, а то каждому отдельно объяснять основы менеджмента и как его не профукать у меня времени нет.
I>То есть, начать революцию с себя, а не с менеджеров Джетбрейнса. Влад наверное думал, что менеджмент будет сидеть сутками на RSDN и читать местные форумы.
А у тебя менджмент это такие люди сидящие безвылазно в своих офисах, работа которых ждать пока к ним придут и принесут готовый продукт? Нахера они вообще тогда нужны? Одного гендира хватит послушать одну презентацию раз в 3 года
I>Расскажи, как продавать эту нитру ? Посмотри, чего в родмапе, вот список профитов за все майлстоны:
Это ты ещё в трэкер какого-нить типового веб-проекта не смотрел. Там вообще иногда появляется "кнопки разместить" и "поле на форму добавить".
I>Типичный менеджер от этого списка придет в ужас.
Типичный менеджер должен этот список формировать на нескольких уровнях. И продавать уровнень где в майлстоуне написано "специфический ЯП с бесшовной интеграцией в C# делается за неделю; расширение синтаксиса linq до insert, update, transaction( <update_query> ) берётся из nuget'a в один клик".
I>До кучи, из родмапа следует, что цель Нитры — это Немерле. Это не просто непонятно, это вводит в заблуждение.
А если посмотреть в сорцы — то всё ещё хуже. Например цель одного из классов — грузить метаинформацию со сборки. Если в этот момент знакомство с проектом завершить — можно окончательно заблудиться. С удовольствием поржу над судьбой любого проекта в котором список текущих задач для разработчиков ведут на уровне рекламных текстов
I>Нужны не трёхчасовые презентации раз в три года, а постоянные демонстрации хоть чего то полезного. Пусть это работает долго и коряво, зато можно потрогать и пощупать.
Этой задачей должны были озаботиться координаторы, зам-тех-диры или кто там в JB отвечает за превращение артели технарей в команду разработки продукта. Навязав кого-то чья задача трогать, щупать и давать обратную связь как пилителям малахитового цветка так и самой компании. И ещё блог вести до кучи. Понадеяться что при конфликте ролей всё разрулится — это профукать основы. Собственно я уже об этом тут писал.
I>Кроме того, языки программирования сами по себе не летают. С момента выпуска проходит много времени, прежде чем начнется собственно сама монетизация. Потому фремворк изготовления языков в перспективе рискует окупиться лет через десять.
ЯП дико невыгодно делать потому что из десятка языков программирования — х-з кто выстрелит. Собственно JB это наверное уже прочувствовали как никто другой на примере Kotlin. Зато с фреймворком который интегрируется в IDE — энтузиасты наляпают сотню языков программирования и ещё сотню аддонов к C#. Один выстрелил — и вот у тебя тулчейн продаётся огромным тиражом. При бесплатном фреймворке. Но эту мысль невозможно подумать если всё время искать "кому бы втюхать фреймворк за бапки"?
Здравствуйте, hi_octane, Вы писали:
I>>То есть, начать революцию с себя, а не с менеджеров Джетбрейнса. Влад наверное думал, что менеджмент будет сидеть сутками на RSDN и читать местные форумы. _>А у тебя менджмент это такие люди сидящие безвылазно в своих офисах, работа которых ждать пока к ним придут и принесут готовый продукт? Нахера они вообще тогда нужны? Одного гендира хватит послушать одну презентацию раз в 3 года
У нас менеджеры получают ЗП за то, что команда забивает голы. А ты и Влад ждете, что менеджеры сами будут по полю бегать
I>>Расскажи, как продавать эту нитру ? Посмотри, чего в родмапе, вот список профитов за все майлстоны: _>Это ты ещё в трэкер какого-нить типового веб-проекта не смотрел. Там вообще иногда появляется "кнопки разместить" и "поле на форму добавить".
Если про большие майлстоны, то никаких кнопок там не будет, там перечисляются самые важные фичи с точки зрения пользователя. Например "убер-поиск" или "интеграция с биллинговой системой".
I>>Типичный менеджер от этого списка придет в ужас. _>Типичный менеджер должен этот список формировать на нескольких уровнях. И продавать уровнень где в майлстоуне написано "специфический ЯП с бесшовной интеграцией в C# делается за неделю; расширение синтаксиса linq до insert, update, transaction( <update_query> ) берётся из nuget'a в один клик".
Менеджер может помочь команде родить эти строчки. Он вообще может не знать, не обязан ни что такое Немерле, Нитра ни чем peg лучше парсер-комбинаторов. Что продаётся — менеджер может подсказать. Но если принциапиально новая идея, как Влад утверждает, то никакой менеджер эту работу не сделает.
I>>До кучи, из родмапа следует, что цель Нитры — это Немерле. Это не просто непонятно, это вводит в заблуждение. _>А если посмотреть в сорцы — то всё ещё хуже. Например цель одного из классов — грузить метаинформацию со сборки. Если в этот момент знакомство с проектом завершить — можно окончательно заблудиться. С удовольствием поржу над судьбой любого проекта в котором список текущих задач для разработчиков ведут на уровне рекламных текстов
Текучка всегда привязана к глобальным фичам. И время от времени демонстрируются именно эти фичи. Никто в бизнесе не будет смотреть демо "ошибка перезаписывается если восстановление сваливается по неизвестной причине". На демо выносится вот такая вещь "корректное сообщение о фатальном сбое"
_>Этой задачей должны были озаботиться координаторы, зам-тех-диры или кто там в JB отвечает за превращение артели технарей в команду разработки продукта.
I>У нас менеджеры получают ЗП за то, что команда забивает голы. А ты и Влад ждете, что менеджеры сами будут по полю бегать
Какая-то странная аналогия. В случае программирования — бегать по полю это писать код. Где ты сумел прочитать что менеджеры должны писать код? Ты лучше напиши что по-твоему они вообще должны делать? Вот случилось 9 утра, пришли, включили компы, дальше что? У тебя получается что дальше всё — пьём кофе и ждём пока "команда забьёт голы"...
I>Менеджер может помочь команде родить эти строчки. Он вообще может не знать, не обязан ни что такое Немерле, Нитра ни чем peg лучше парсер-комбинаторов. Что продаётся — менеджер может подсказать. Но если принциапиально новая идея, как Влад утверждает, то никакой менеджер эту работу не сделает.
Ну то есть менеджер продукта вообще никакого представления о продукте не имеет? Приехали. Правильный ответ: что продаётся подсказывают сейлзы. А ты почитай хоть одну книгу где упоминается роль "продукт-менеджер".
I>Теоретически — обязаны. Но что было унутре, не ясно. Информация только от одной стороны.
Тебе может и неясно, а я прежде чем даже появились коменты Влада пробежался по их трэкеру и посмотрел — со стороны людей из JB практически 0 правок роадмапа, коммитов каких-то оценок и графика закрытия фич, и т.п. Только работа трёх бойцов зондер-команды. Это значит они были пущены в свободное плавание, а со стороны конторы было просто ожидание что дальше само.
I>Я думаю здесь скорее однобокое мнение на тему происходившего.
3 года работы, технари которые готовят презентацию продукта и сами же ведут роадмап — это факты а не мнение. Когда я был джуном на моих глазах техдир составил точное мнение о приближающемся факапе по единственному наблюдению что "за последний месяц в мылах между отделами мелькают одни и те же темы". Вот это был вывод в условиях когда было реально мало информации а ПМы откровенно гнали пургу уверяя что "всё ок". А тут информации для однозначного мнения более чем достаточно.
Здравствуйте, hi_octane, Вы писали:
I>>У нас менеджеры получают ЗП за то, что команда забивает голы. А ты и Влад ждете, что менеджеры сами будут по полю бегать _>Какая-то странная аналогия. В случае программирования — бегать по полю это писать код. Где ты сумел прочитать что менеджеры должны писать код? Ты лучше напиши что по-твоему они вообще должны делать? Вот случилось 9 утра, пришли, включили компы, дальше что? У тебя получается что дальше всё — пьём кофе и ждём пока "команда забьёт голы"...
Писать код это обязанность джуниора. Дальше обязанностей только добавляется. Инженер обязан знать и понимать, как и для чего будут применяться его решения.
I>>Менеджер может помочь команде родить эти строчки. Он вообще может не знать, не обязан ни что такое Немерле, Нитра ни чем peg лучше парсер-комбинаторов. Что продаётся — менеджер может подсказать. Но если принциапиально новая идея, как Влад утверждает, то никакой менеджер эту работу не сделает. _>Ну то есть менеджер продукта вообще никакого представления о продукте не имеет? Приехали. Правильный ответ: что продаётся подсказывают сейлзы. А ты почитай хоть одну книгу где упоминается роль "продукт-менеджер".
Продукт и техническая его сторона вещи разные. Сейлз — это не ясно. Это везде разные обязанности. Обычно это продажники, они знают только то, что продаётся сейчас. А вот стратегический маркетинг лежит не на продажниках, а вообще на менеджменте.
Что касается книжек, то под продукт-менеджером обычно понимается все что угодно, от продукт-овнера до проджект-менеджера и иногда даже бизнес-аналитик.
_>Тебе может и неясно, а я прежде чем даже появились коменты Влада пробежался по их трэкеру и посмотрел — со стороны людей из JB практически 0 правок роадмапа, коммитов каких-то оценок и графика закрытия фич, и т.п. Только работа трёх бойцов зондер-команды. Это значит они были пущены в свободное плавание, а со стороны конторы было просто ожидание что дальше само.
Это все равно часть фактов. Может Влад им три года обещал "вот щас дофиксим и покажем" ?
_>3 года работы, технари которые готовят презентацию продукта и сами же ведут роадмап — это факты а не мнение.
I>>>У нас менеджеры получают ЗП за то, что команда забивает голы. А ты и Влад ждете, что менеджеры сами будут по полю бегать _>>Какая-то странная аналогия. В случае программирования — бегать по полю это писать код. Где ты сумел прочитать что менеджеры должны писать код? Ты лучше напиши что по-твоему они вообще должны делать? Вот случилось 9 утра, пришли, включили компы, дальше что? У тебя получается что дальше всё — пьём кофе и ждём пока "команда забьёт голы"... I>... джуниора. Инженер ...
Я те на демагогию спрыгнуть не дам. Болдом конкретный вопрос про роль менеджера, в котором нет ни слова джуниор, ни слова инженер.
_>>Ну то есть менеджер продукта вообще никакого представления о продукте не имеет? Приехали. Правильный ответ: что продаётся подсказывают сейлзы. А ты почитай хоть одну книгу где упоминается роль "продукт-менеджер". I>Продукт и техническая его сторона вещи разные. Сейлз — это не ясно. Это везде разные обязанности. Обычно это продажники, они знают только то, что продаётся сейчас. А вот стратегический маркетинг лежит не на продажниках, а вообще на менеджменте.
Стратегические решения были приняты когда команду решили взять на борт. С этого момента за превращение сорцов в продукт отвечать должны конкретные люди, а не некий мифический "вообще".
I>Что касается книжек, то под продукт-менеджером обычно понимается все что угодно, от продукт-овнера до проджект-менеджера и иногда даже бизнес-аналитик.
И хоть один из них впахал со стороны JB?
_>>Тебе может и неясно, а я прежде чем даже появились коменты Влада пробежался по их трэкеру и посмотрел — со стороны людей из JB практически 0 правок роадмапа, коммитов каких-то оценок и графика закрытия фич, и т.п. Только работа трёх бойцов зондер-команды. Это значит они были пущены в свободное плавание, а со стороны конторы было просто ожидание что дальше само. I>Это все равно часть фактов. Может Влад им три года обещал "вот щас дофиксим и покажем" ?
И что? Так все везде обещают. Превращать эти обещания в реалистичные цифры часть работы менеджера. Прочитай таки всю тему — я уже писал
что на любых курсах по управлению учат как работать с оценками технарей.
_>>3 года работы, технари которые готовят презентацию продукта и сами же ведут роадмап — это факты а не мнение. I>Часть фактов. А где остальное ?
А ты можешь гипотетически придумать хоть один который бы радикально изменил картину?
Здравствуйте, hi_octane, Вы писали:
_>>>Какая-то странная аналогия. В случае программирования — бегать по полю это писать код. Где ты сумел прочитать что менеджеры должны писать код? Ты лучше напиши что по-твоему они вообще должны делать? Вот случилось 9 утра, пришли, включили компы, дальше что? У тебя получается что дальше всё — пьём кофе и ждём пока "команда забьёт голы"... I>>... джуниора. Инженер ... _>Я те на демагогию спрыгнуть не дам.
В демагогию ты сам лезешь, подымись выше по ветке и убедись про что речь. "Продавать = доносить свои решения до руководства. Нужно поддерживать интерес руководства, демонстрировать профит, прогресс, возможности. Для этого нужно самому в первую очередь планировать свою работу определенным образом. "
Вот это — обязательно. А уже после этого можно требовать чего то от руководства.
>Болдом конкретный вопрос про роль менеджера, в котором нет ни слова джуниор, ни слова инженер.
У менеджеров — поддержание коммуникации, принятие решений в специчной области, измерение затрат и результатов, оргвопросы, цели и приоритеты. Коммуникация, например, совсем не означает, что менеджер будет говорить за инженера или рот ему раскрывать. Цели и приоритеты — сведения только одной стороны, менеджмент вряд ли расскажет, как они видели Нитру.
В маленьких командах менеджер всего лишь роль и её явно или неявно несет лидер команды. Он же и принимает решения. Теперь возникает вопрос — кто из трех был лидером ? Неужели все три линейные девелоперы ? Я в это не поверю
Допустим, менеджер ушел, эдакий босяк. Кто взял на себя обязанности выше ? Неужели никто не был готов взять на себя ответсвенность ? Никто не понимал, что это уже проблема ? Не было внимания-интересу ажно три года ?
А куда исполнители смотрели ? У исполнителя есть обязанность вообще говоря, интересоваться судьбой своих решений. А у менеджера обязанность эту информацию предоставлять. И отсутствие выделенного менеджера ни разу не является проблемой. Это следует из простого факта, что как прижгло, так Влад по его же словам сразу нашел, куда и к кому надо идти.
Получается у команды был руководитель группы, хотя и неявный, то есть, тот самый менеджер. Плохой руководитель, что очевидно. Это мнение подтверждается неиспользованым отпуском, проблемами в коммуникации, усталостью команды и тд и тд.
I>>Продукт и техническая его сторона вещи разные. Сейлз — это не ясно. Это везде разные обязанности. Обычно это продажники, они знают только то, что продаётся сейчас. А вот стратегический маркетинг лежит не на продажниках, а вообще на менеджменте. _>Стратегические решения были приняты когда команду решили взять на борт. С этого момента за превращение сорцов в продукт отвечать должны конкретные люди, а не некий мифический "вообще".
По моему речь про R&D а не продуктовую разработку. Здесь тебе никто не поможет, если ты сам не захочешь.
I>>Что касается книжек, то под продукт-менеджером обычно понимается все что угодно, от продукт-овнера до проджект-менеджера и иногда даже бизнес-аналитик. _>И хоть один из них впахал со стороны JB?
Эта часть информации отсутствует. Ты почему то хочешь заполнить пробел отсебятиной Влада. На каком основании ?
I>>Это все равно часть фактов. Может Влад им три года обещал "вот щас дофиксим и покажем" ? _>И что? Так все везде обещают. Превращать эти обещания в реалистичные цифры часть работы менеджера.
Это какая то дичь. У тебя какой то опыт сильно специфический. Я все время работаю в продуктовых проектах и такое первый раз слышу. Начиная с синьора инженер обязан выдавать проверяемые оценки и помогать планированию.
I>>Часть фактов. А где остальное ? _>А ты можешь гипотетически придумать хоть один который бы радикально изменил картину?
Чисто гипотетически — менеджеры отчаялись получить от Нитры внятных сроков, хоть какой то управляемости, предсказуемости, хотя бы внятного описания пользы-профита, хоть каких то демок внятных и тд и тд. Три года терпели-терпели-терпели...
_>>>>Какая-то странная аналогия. В случае программирования — бегать по полю это писать код. Где ты сумел прочитать что менеджеры должны писать код? Ты лучше напиши что по-твоему они вообще должны делать? Вот случилось 9 утра, пришли, включили компы, дальше что? У тебя получается что дальше всё — пьём кофе и ждём пока "команда забьёт голы"... I>>>... джуниора. Инженер ... _>>Я те на демагогию спрыгнуть не дам. I>У менеджеров — поддержание коммуникации, принятие решений в специчной области, измерение затрат и результатов, оргвопросы, цели и приоритеты. Коммуникация, например, совсем не означает, что менеджер будет говорить за инженера или рот ему раскрывать.
Представь себя тех-диром. Вызываешь ты себе на ковёр менеджера и говоришь — "там твои три года пилят чего-то, не знаешь чего примерно?" А он тебе "х-з, жду-жду, а они замкнутые какие-то, нихера мне не говорят". Как думаешь, ты ему на это скажешь "а ну ладно, иди, жди ещё, может потом скажут чего"? Прям дзэн-буддисты познающие смирение а не контора
I>Цели и приоритеты — сведения только одной стороны, менеджмент вряд ли расскажет, как они видели Нитру.
Как бы не видели — профиль компании за это время не поменялся, и в роадмапе нитры ни одна фича не была завёрнута с пометкой "простите, но это оказалось нереально". Т.е. ситуация по сравнению с тем что было в момент принятия решения о покупке куда более предсказуемая и понятная.
I>В маленьких командах менеджер всего лишь роль и её явно или неявно несет лидер команды. Он же и принимает решения. Теперь возникает вопрос — кто из трех был лидером ? Неужели все три линейные девелоперы ? Я в это не поверю
А вот на внутреннюю структуру тех кто пишет код плевать — сами лучше разберутся. Главное следить (руководству, не им) чтобы противоречивые роли не повисли на одном человеке. Такая-же, кстати, основа основ как и учёт метрик для уточнения оценок сроков. В данном случае на ком-то из разработчиков повисли роли и менеджера продукта и девелопера. Увы, даже ветхие мануалы 15-летней давности говорят что это не взлетит.
I>Допустим, менеджер ушел, эдакий босяк. Кто взял на себя обязанности выше ? Неужели никто не был готов взять на себя ответсвенность ? Никто не понимал, что это уже проблема ? Не было внимания-интересу ажно три года ?
И вот такие вопросы нас плавно приведут к тому что команда была, а управления не было. Кто отвечает за управление? Твой пойнт понятен — они сами и отвечают. Так если технари должны всё сами, возвращаемся к вопросу нафига тогда вообще девелоперам менеджмент
I>>>Что касается книжек, то под продукт-менеджером обычно понимается все что угодно, от продукт-овнера до проджект-менеджера и иногда даже бизнес-аналитик. _>>И хоть один из них впахал со стороны JB? I>Эта часть информации отсутствует. Ты почему то хочешь заполнить пробел отсебятиной Влада. На каком основании ?
На основании опыта в добывании информации и опыта работы. Мне суть происходящего стала понятна задолго до того как Влад хоть что-то написал. Конкретно за два месяца до того как Legion13 эту тему поднял. Просто по наблюдению за confluence, коммитам и постам вроде этого
.
_>>И что? Так все везде обещают. Превращать эти обещания в реалистичные цифры часть работы менеджера. I>Это какая то дичь. У тебя какой то опыт сильно специфический. Я все время работаю в продуктовых проектах и такое первый раз слышу. Начиная с синьора инженер обязан выдавать проверяемые оценки и помогать планированию.
В богатых продуктовых конторах могут вообще никакой оценки не делать — в случае неверной оценки передвинут релиз или перенесут фичу в следующий релиз и всего-то. А для тех кому точные сроки хоть сколько-то важны за последние лет 10 вышла куча мануалов упоминающих story points и как их потом переводить в часы. Но в общем это "первый раз слышу" вполне согласуется с невозможностью сказать зачем вообще на проектах менеджеры кроме как ждать пока синьёры всё сами сделают.
I>>>Часть фактов. А где остальное ? _>>А ты можешь гипотетически придумать хоть один который бы радикально изменил картину? I>Чисто гипотетически — менеджеры отчаялись получить от Нитры внятных сроков, хоть какой то управляемости, предсказуемости, хотя бы внятного описания пользы-профита, хоть каких то демок внятных и тд и тд. Три года терпели-терпели-терпели...
Ну то есть ждали-ждали-ждали. Круг замкнулся
Здравствуйте, hi_octane, Вы писали:
_>Даже в Минске (причём тут зарплаты не падали в 2 раза т.к. привязаны к доллару), даже не продуктовые а аутсорс конторы, числом меньше 100 человек, спокойно держат и больше людей на исследовательских направлениях.
На исследовательских направлениях люди или по совместительству, или на особых условиях, или конторы крупные, или конторые продуктовые. Для конторы меньше 100 да аутсорс очень накладно держать R&D. У них заработок N-разрабов помножить на рейт — прибыль ничтожная.
_>В моей реальности как MS не выкатит новое дополнение в C# — так сразу крики ура и все побежали копировать от Java до C++. Пиарщики go ухитряются впихивать никакущий генератор как важную фичу. А у маркетологов JB "как продать возможность расширять язык — неизвестно".
Именно потому и неизвестно. Если ты напихаешь в язык расширений, то большей частью через год-полгода их придется выкинуть, потому что в новой версии языка будет все иначе. Нужно не расширение, а сужение возможностей. Про это AVK еще десять лет назад говорил.
_> то что без известных метрик срок технаря надо множить на кэф от пи до пи-квадрат вам говорили?), остались недовольны тем "что им это не продали", и вместо того чтобы назначить кризисного управляющего с задачей "разберись за месяц-два что там происходит", закрыли проект.
Потому что во всех остальных случаях пишут одни а продают другие...
