Здравствуйте, Aikin, Вы писали:

A>Но это фигня. Я не знаю когда дорасту до уровня, когда смогу спросить что-то действительно стоящее.

"За спрос", уважаемый Айкин, даже на зоне не бьют. Не то что в таком куда более приличном месте, как в ЖЖ.

А вот за переходы на личности...

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Аноним, Вы писали:

S>>>1. с тех пор, как я бросил проджект менеджмент, люди придумали много интересных теорий (большинство из которых не очень хорошо применимы на практике).
А>>И на что ты его поменял?
S>на менеджмент продуктов. Людьми я управлять не люблю. Понятия не имею, чего все так стремятся к этой "власти". Управлять требованиями гораздо интереснее.

О. Теперь я понимаю, почему тебя так цепанул тот мой пост. Единственное, что я не понимал в нашей беседе.

Бывает, Синклер. Ниче, не переживай — с людьми работать, оно не каждому дано. Это куда сложнее, чем MS Project, дискуссии с безмозглыми тренерами, и "работы с требованиями".

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

Ясен хрен, надо такого уволить. Из элементарной логики следует. Замени его скриптом — толку будет столько же, а насколько меньше гундежа!

Здравствуйте, Eye of Hell, Вы писали:

G>>Ты хочешь, чтобы я его тебе в деталях, подробно, и по шагам воспроизвел в форуме? Зачем? Тебе что-то мешает самому нажать кнопку Help?

EOH>Извиняюсь что заползаю в дискуссию — зачем на форуме?

Иногда, по старой памяти, когда совсем нехер делать, я захожу сюда. Затем на этом форуме. Я его, все-таки, люблю. Где-то в глубине дущи.

EOH>Думаю, многие вам будут благодарные, а сами вы получите еще +20 к известности и +1 к менеджерству...

Нахрен не вперлось. Вы, если интересно, наберите "gaperton" в поиске по блогам, скажем, в яндексе. Мой блог в ЖЖ имеет большую аудиторию, чем этот форум. И статьи в нем сами перепечатываются туда, куда нужно.

Хабр — лишний.

Здравствуйте, Eye of Hell, Вы писали:

EOH>Надеюсь, никто не обидится если я и сюда заползу?

И тут внезапно все подумали. И половина решила обидеться.

EOH>Досточтимый и многомудрый Gaperton, а почему вы считаете что для любой задачи основное — это критерий завершения?

Опыт. Когда я говорю об этом, я действительно знаю[b/], о чем говорю. Есть вещи, в которых я не уверен, и их много — но в этом уверен как никогда. Представляете себе? Такое иногда бывает.

EOH> Насколько я помню, процессы обычно подгоняют под наиболее [b]частый случай.

Странно, а я вот такого не помню, хоть и "многомудрый" (льстите мне, льстите). Я вообще, если какой херни не помню — то не стараюсь делать вид, что помню. Советую, кстати, Вам брать с меня пример.

EOH> Если у нас при копании траншей наиболее частый случай — "выкопали", то ежу понятно что основное что нам о задаче интересно — это "выкопали или не выкопали". Варинт "копали, выкопали трубопровод, теперь не знаем что делать" случается очень редко, мы его рассматриваем как исключение.

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

EOH>Разработка программного обеспечения — область ебанутая сложная отличная от копания траншей. И от вытачивания заготовок на станках — тоже.

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

EOH>У нас как раз ситуации когда "копали, а ночью все само зарасло", "копали — выкопали BSOD", "копали — докопались до лавы" — это то, что случается каждый день. Очень редко случается что мы в последующем проекте применяем точно те же технологии что и в предыдущем, для решения тех же задач. Потому как у нас нулевая цена копирования и если кто-то уже выокпал траншею — нам не нужно копать следующую. Мы копируем уже выкопанную. Так что каждый следующий проект — это копание траншей новой формы на новой планете с не очень понятными физическими законами и с новым набором инструментов. И вариант что оно выкопалось — это не самый частый случай. Самый частый случай — это выкопались те или иные проблемы, с которыми мы как-то работаем дальше — начиная от разбиения задачи и заканчивая ее изменением / отменой.

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

EOH>Вы согласны с вышеизложенным? Или считаете что критерий "выполнено/не выполнено" основной вне зависимости ни от чего?

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

Здравствуйте, Eye of Hell, Вы писали:

EOH>Какие-нибудь факты, аргументы?

Очень по хабровски. У нас такое поведение вт ИТМиВТ называли — "умняк накинуть". Разумеется, беседу надо понимать в контексте Вашего поста пару раз выше.

Вы этого здесь ждете, но этого здесь не будет.

EOH>>Разработка программного обеспечения — область ебанутая сложная отличная от копания траншей. И от вытачивания заготовок на станках — тоже.
G>Вы в проектах, где было точение на станках, участвовали? Вот я, например, ими руководил. И они мне очень интересны — расскажите мне про них подробнее — в чем по вашему разница?

Я ими не руководил, но я заказывал изготовление железных деталек в малых тиражаш (от 100 особей). Чем, на мой взгляд, точение заготовки отличается от разработки программного обеспечения — мы такую же или очень похожую заготовку уже сотни раз точили. Мы берем чертеж, смотрим на материал, допуски — и в большинстве случаев сразу понятно, что будет. Бывают исключения — слишком тонкие / толстые части, сложная форма, маленькие допуски — но это редко. И, замчечу — в большинстве случаев, если знаем сапромат — сразу видно.

В программном обеспечении по внешним признакам нифига не видо. Вот возьмем из практики — делали недавно MSI установщик, чтобы значит добрые дядьки админы могли его через active directory на тыщи компов ставить. Простая задача — если драйвер железки в новой версии не изменился — то его не переустанавливаем, ибо к нему могут быть подключены написанные школьниками фильтры и потрбуется перезагрузка — а мы перезагрузки не хотим и драйвер меняется нечасто. Изучив предмет, я оценил риски как средние — гугл показывает что никто про такие извращения не пишет, MSI движок наполовину декларативный, могут быть вопросы. К сожалению, пары часов на то чтобы внимательно изучить MSI API и MSI TABLES у меня не было — в проекте задачи со средними рисками хватает, если все детально изучать — то очень долго, а делать все равно надо (c). Вообщем в неделю прототип не уложился — оказалось, что мой лучший спец по инсталляторам знает об MSI не все. И авторы MSI тоже знают о нем не все. Задачу выполнили — но в три раза дольше чем планировали. Был риск эту фичу дропнуть. И так регулярно.

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

EOH>>У нас как раз ситуации когда "копали, а ночью все само зарасло", "копали — выкопали BSOD", "копали — докопались до лавы" — это то, что случается каждый день. Очень редко случается что мы в последующем проекте применяем точно те же технологии что и в предыдущем, для решения тех же задач. Потому как у нас нулевая цена копирования и если кто-то уже выокпал траншею — нам не нужно копать следующую. Мы копируем уже выкопанную. Так что каждый следующий проект — это копание траншей новой формы на новой планете с не очень понятными физическими законами и с новым набором инструментов. И вариант что оно выкопалось — это не самый частый случай. Самый частый случай — это выкопались те или иные проблемы, с которыми мы как-то работаем дальше — начиная от разбиения задачи и заканчивая ее изменением / отменой.
G>Вот именно поэтому я и не люблю хабр. Я, с Вашего позволения, не буду это комментировать. Выражаться надо проще. Тогда станет очевидно, есть вам что сказать, или нет. А вы это зачем-то глубоко прячете за своими словами.
EOH>>Вы согласны с вышеизложенным? Или считаете что критерий "выполнено/не выполнено" основной вне зависимости ни от чего?
G>Не. Я вышеизложенного тупо не понял. Тупой. Вы, пожалуйста, будьте проще, а то ведь, глядишь — не поймут вас люди. И того больше — смеяться над вами будут. Здесь ведь, всетки, не хабр.

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

P.S. Это я все в рамках топика — о хороших программах для планирования. Бо надо — Jira хорошо автоматизирует документооборот, но вот для планирования приходится выбирать между Greenhopper и MS Project. И ни тот, ни другой мне не нравятся.

Здравствуйте, Аноним, Вы писали:

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

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

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

Почему-то у большинства коллег по цеху в голове ассоциация "эстимейт есть документ, которому нужно соответствовать во что бы то ни стало". Когда до меня дошло, что эстимейт в программировании есть всего лишь прогноз — жизнь стала куда проще. Ибо не может быть точных сроков и расписаний в условиях неопределенности, большей нуля. Не надо путать конвейрное и кастомное производство. В первом случае — всё известно заранее, нарушить эстимейт может лишь ЧП типа выхода из строя оборудования, отключеения энергии, забастовки. Во втором случае — мы играем на терра инкогнита, I'm feeling lucky... ой, уже не настолько lucky... упс, шеф, да тут вообще такое, оказывается...
Поэтому менеджер должен уметь не только ходить на митинги, но и мониторить ход проекта, чтобы понять, где начинается расхождение с эстимейтами, а затем пойти к заказчику и проговорить ситуацию. Собственно, скрамовские стендапы именно для этих целей и нужны — понять, что где-то что-то идёт не так.

MD> Собственно, скрамовские стендапы именно для этих целей и нужны — понять, что где-то что-то идёт не так.

Я даже больше скажу, собственно, весь скрам и нужен для этой цели — понять, что "что-то идет не так" (С) максимально рано.

Здравствуйте, Gaperton, Вы писали:

Сорри, что так поздно отвечаю -- не часто на форум заглядываю.

G>Удивительно, что ты один из моих лучших "учеников".
Лестно, очень лестно. Спасибо! Получить такой отзыв от от человека которого я действительно очень уважаю. Очень приятно.

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


G>, и до кучи еще и регулярно срешься в мной комментах.
G>Впрочем, как говорят знающие люди, последнее качество всегда отличало годного combat officer .
Угу, но я не мог пройти мимо некоторых твоих высказываний.


G>Предлагаю как-нибудь лично познакомиться на каком-нибудь мероприятии, конференции например. Почта как ник в gmail, если есть желание пиши.
С удовольствием. Я на почту отпишусь.


СУВ, Aikin

P.S. С преогромным удовольствием поработал бы с тобой. В любом качестве. Чисто за опыт. Деньги и на текущем месте работы неплохо зарабатываются. Другое дело, что уже около 2х лет идет период слабого, очень слабого роста, если не сказать застоя. В связи с чем ищется возможность встряхнуться, перодолеть порог и расти дальше.
Очень хочется, но боюсь это практически невозможно. Семья, дети, возраст не способствует авантюрам. (30, если что )

A>Очень хочется, но боюсь это практически невозможно. Семья, дети, возраст не способствует авантюрам. (30, если что )

Как раз когда австралийские студенты заканчивают университеты и начинают авантюры.

Здравствуйте, SkyDance, Вы писали:

A>>Очень хочется, но боюсь это практически невозможно. Семья, дети, возраст не способствует авантюрам. (30, если что )

SD>Как раз когда австралийские студенты заканчивают университеты и начинают авантюры.
Другая культура -- другой возраст взросления.
Ну и, про возраст это была такая шутка, там даже смайлик стоит Главный "стоп-кран" -- это все же жена и ребенок. Больше жена, если что (уж очень консервативна, ей одна синица здесь лучше сотни журавлей где-то там).

СУВ, Aikin

Здравствуйте, stranger_v, Вы писали:
_>Здравствуйте, maxkar, Вы писали:

M>>Есть, например, task adapter, он как минимум в одном направлении поможет данные перегонять. Может быть, сможет и в обратном направлении синхронизировать. Если интересно, спросите автора (alskor), он вам подробнее расскажет.
_>229 долларов в месяц. Для нашего проекта это пока много... Тем более, мы нашли достойную бесплатную альтернативу JIRA. Я об этом напишу в посте ниже.

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

у Таск Адаптера, конечно, много ограничений. но он умеет делать перенос данных из джиры в проджект и обратно. в т.ч. есть функция "обновить МСП файл". т.е. создаем файл проекта в МСП, экспортируем в джиру с сохранением Jira task IDs. потом можно обновить задачи в файле.
это, конечно, не идеал. но есть своя область применения.