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

E>А вы чего думаете?

Что за проект ? Сомневаюсь, что молодой, малоопытный программист способен сделать какой-либо серьезный проект в одиночку за месяц.
Надо это ему просто объяснить. Это лишь поначалу кажется, что стоит ночку и выходные посидеть и все напишется.

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

_O_>Что за проект ? Сомневаюсь, что молодой, малоопытный программист способен сделать какой-либо серьезный проект в одиночку за месяц.

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

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

E>А вы чего думаете?

Я думаю что менеджер — лошара.

1) менеджер должен выяснить причину конфликта, попытаться устранить конфликт, а не чье-то мнение.
2) гипотезу программиста очень легко проверить, дав ему сделать часть работ и сравнить реальные результаты. Буквально за неделю можно получить объективный результат.

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

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

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

E>>А вы чего думаете?

_O_>Что за проект ? Сомневаюсь, что молодой, малоопытный программист способен сделать какой-либо серьезный проект в одиночку за месяц.
_O_>Надо это ему просто объяснить. Это лишь поначалу кажется, что стоит ночку и выходные посидеть и все напишется.

А с чего ты взял что он молодой и малоопытный? Это домыслы, в оригинальном посте автор об этом не писал.

Я, кстати, вживую видел как один толковый программист делал быстрее и лучше чем 3 программиста подрядчиков. Опыт примерно одинаковый был.

S>Почему бы не попросить программиста составить детальный план, в котором он докажет, что сделает за месяц.
S>Чтобы доказать что сделает, пусть оформит документацию (список фич).
S>Чтобы доказать, что фичи нужные, пусть оформит список требований (и кто за эти требования отвечает).
S>Как только он попытается это проделать, вопросы, почему требуется много времени, у программиста отпадут.

Ага, потому что программист уволится. Конечно, если он не дурак. Опытные программисты прекрасно понимают — как только у них требуют работать за себя, а также за аналитиков, program manager'ов, юзабилистов и других персон, это лишь означает, что их довольно бездарно "разводят".
Методика разводки классическая: "ты пока выполняй свои старые обязанности, и в свободное от этого время составляй план, список фич и прочее".

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

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

G> Приемка требует много чтения кода
читать код обычно приходится когда нет документации и сам код небрежно написан. у меня есть опыт участия в приемке. на код там вообще никто не смотрел. сначала долго и вдумчиво читали спецификацию с кучей "самопальных" аббревиатур и тонной диаграмм, иллюстрирующих процесс черточками и стрелочками с мелким-мелким шрифтом.

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

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

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

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

E>* уволить программиста — не сдадим проект в срок

Увольнять надо не программиста, а горе-менеджера.
Потому что:
1. Вместо того, чтобы заниматься коммуникациями с внешними поставщиками, менеджер всё спихнул на кого-то.
2. Менеджер не в курсе деталей конфликта с внешней стороной.
3. Менеджер не соизволил погасить конфликт в зародыше, дал конфликту созреть и вырасти в открытое противостояние.
4. Менеджер винит свою команду, вместо того, чтобы ее защищать.

Позволю себе лирическое отступление и сравнение подхода к менеджменту и руководству у представителей разной ментальности. На примере политики США и России. США за их внешнюю политику ненавидит пол-мира. Потому что в случае чего, разборки будут не на территории США. Граждане США будет довольны. Потому что государство их защищает.
Как это происходит в России? Ограбить соседние государство чиновничья верхушка России не в силах. И, ничтоже сумняшеся, грабит собственный народ. В случае чего, граждане России первыми же и попадают под удар. Бей своих, чтобы чужие боялись.

После такого лирического отступления становится проще объяснить и поведение упомянутого "менеджера". Вероятно, у него нет рычагов влияния на внешних поставщиков. Равно как нет и желания (умения?) искать дипломатическое решение. Куда проще обвинить в саботаже собственного работника. Свалить провал на него.


E>* убедить программиста работать с подрядчиком — не убеждается

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

E>* выпереть программиста, повысить помощника — помощник не до конца в теме

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

Проказница-Мартышка,
Осёл,
Козёл,
Да косолапый Мишка
Затеяли сыграть Квартет.

Разумеется, он, как положено истинно воспитанному человеку, не дочитывал до конца. Но намек был более чем прозрачен:

А вы, друзья, как ни садитесь,
Всё в музыканты не годитесь».

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

E>Там еще более 300 комментов. Выжимка:
E>* уволить программиста — не сдадим проект в срок
E>* пойти на поводу программиста — не сдадим проект в срок + поощрение шантажа
E>* убедить программиста работать с подрядчиком — не убеждается
E>* выпереть программиста, повысить помощника — помощник не до конца в теме

Очень важно еще уметь читать то что НЕ написано.

1) Почему так получилось что весь проект завязан на одного программиста?
2) Где же тестеры? Как вообще осуществляется приемка? Почему её делает один программист?
3) Почему нет формализованной процедуры приемки? Чем РП вообще занимается на этом проекте?
4) В комментах пару раз проскочило что ТЗ на самом деле ХЗ и сделать по нему ничего нельзя, нужен носитель знаний, очень странно что это программист, а не аналитик. Тоже фейл.
5) Вполне возможно что программист в этой ситуации прав и он быстрее будет писать код сам, чем принимать от подрядчика. Это не значит что подрядчики плохие, это скорее всего, процесс плохой.

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

Здравствуйте, мыщъх, Вы писали:

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

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

G>> Приемка требует много чтения кода
М>читать код обычно приходится когда нет документации и сам код небрежно написан. у меня есть опыт участия в приемке. на код там вообще никто не смотрел. сначала долго и вдумчиво читали спецификацию с кучей "самопальных" аббревиатур и тонной диаграмм, иллюстрирующих процесс черточками и стрелочками с мелким-мелким шрифтом.

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

Видимо выделенное и было причиной что код не читал.

Я большую при приемке первое что делаю — читаю код. Это же обычно и последнее.

М>кстати, даже хорошо структурированный и комментированный код читать дольше чем писать и еще предметной областью владеть надо. можно нагуглить исходники арифметического компрессора (алгоритм один из самых простых и оно укладывается в сотню строк кода). долго же вы будете его читать если раньше с таким не сталкивались. а если сталкивались и знаете, то зачем это кому-то поручать?
Большинство реализаций алгоритмов из интернета отличается крайне низкой читаемостью. Это делается в угоду быстродействию.

Вот недавно читал код хаффмана на F# в блоге — очень легко, несмотря на то что типов почти нет. А потом для сравнения нагуглил исходник на C, плакал кровавыми слезами, даже студия не помогла.


М>обычно подрядчикам поручают то, что сами либо не знают как, либо рука не набита/наработок нет. довольно часто становится, что исполнитель пишет на языке не знакомом для команды заказчика (или это знакомство очень поверхностно без углублений в трудные места).
Обычно подрядчикам решение слабо формализованной проблемы, а не решение конкретной задачи. От этого и появляются такие посты.
Это практика в России такая, я хз что у вас за океаном творится.

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

E>>* уволить программиста — не сдадим проект в срок

SD>Увольнять надо не программиста, а горе-менеджера.
SD>Потому что:
SD>1. Вместо того, чтобы заниматься коммуникациями с внешними поставщиками, менеджер всё спихнул на кого-то.
SD>2. Менеджер не в курсе деталей конфликта с внешней стороной.
SD>3. Менеджер не соизволил погасить конфликт в зародыше, дал конфликту созреть и вырасти в открытое противостояние.
SD>4. Менеджер винит свою команду, вместо того, чтобы ее защищать.

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

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

_AB>Вообще-то, если перейти по ссылке, то будет ясно, что этому менеджеру поручили разобраться с уже сложившейся
_AB>ситуацией. Этакий кризис-менеджер, можно сказать.

Речь про предыдущего менеджера, который к этому кризису привёл.

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

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

SD>1. Вместо того, чтобы заниматься коммуникациями с внешними поставщиками, менеджер всё спихнул на кого-то.
SD>2. Менеджер не в курсе деталей конфликта с внешней стороной.
SD>3. Менеджер не соизволил погасить конфликт в зародыше, дал конфликту созреть и вырасти в открытое противостояние.
SD>4. Менеджер винит свою команду, вместо того, чтобы ее защищать.

+4
но Вас правильно поправили ниже, что это все к прошлому менеджеру, а не к новому.

SD>На примере политики США и России.

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

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

MTD>Я с вас, телепатов, не перестаю удивляться. А ну как он крайне опытный, да и проект к тому же ему очень хорошо знаком, есть наработанная база.

Крайне опытные способно аргументировано убедить начальство в своей правоте и саботировать процесс не будут.

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

AK>В данном случае за все ответит программист, которого уволят.
Ответит тот, кто потратил деньги с нулевым результатом, если это, конечно, не попил.
А программист просто сменит работу на более приличную. Вообще, если кто-то вдруг в этом программисте узнал себя, то самое лучшее начать срочно искать другую работу, пусть "эффективные менеджеры" сами с собой развлекаются.

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

SD>Позволю себе лирическое отступление и сравнение подхода к менеджменту и руководству у представителей разной ментальности. На примере политики США и России. США за их внешнюю политику ненавидит пол-мира. Потому что в случае чего, разборки будут не на территории США. Граждане США будет довольны. Потому что государство их защищает.
SD>Как это происходит в России? Ограбить соседние государство чиновничья верхушка России не в силах. И, ничтоже сумняшеся, грабит собственный народ. В случае чего, граждане России первыми же и попадают под удар. Бей своих, чтобы чужие боялись.

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

С разбором исходной ситуации согласен.

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

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

E>>>* уволить программиста — не сдадим проект в срок

_AB>Вообще-то, если перейти по ссылке, то будет ясно, что этому менеджеру поручили разобраться с уже сложившейся
_AB>ситуацией. Этакий кризис-менеджер, можно сказать.

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

G>Вот недавно читал код хаффмана на F# в блоге — очень легко, несмотря на то что типов почти нет. А потом для сравнения нагуглил исходник на C, плакал кровавыми слезами, даже студия не помогла.

Сам принцип кодирования по Хафману довольно прост, и хорошо описан в литературе.
Что бы с ним ознакомится, читать левые бложики совсем не надо, можно например прочесть RFC от gzip, помимо Deflate там описаны все принципы кодирования по Хафману.

Реализаций декодирования довольно много — наиная от примитивных просмотров битов в цикле, заканчивая использованием lookup таблиц. Но в целом там нет ничего сложного, все гениальное — просто.

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

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

Примерно так бы я и поступил будь я на его месте. Но я не программист и не менеджер.
И есть в связи с этим у меня один вопрос ниже.

K>Принимать решение в данной ситуации самому менеджеру не стоит.

Зачем нужен менеджер, если он боится принимать решения в рамках своей компетенции?
Или это не его компетенция? Но тогда он скорее аудитор, а не менеджер получается?

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

G>Видимо выделенное и было причиной что код не читал.
G>Я большую при приемке первое что делаю — читаю код. Это же обычно и последнее.

Если бы я читал весь код, который нам делают подрядчики, я бы уже давно бы помер.
Просто так скажу, что у нас Warehousing система и для нее есть несколько плагинов, которые делают сторонние фирмы. Так вот, эти плагины на столько гигантские, что прочитать код даже теоритически нереально в короткое время.
Поэтому у меня есть просто несколько наборов тестовых данных, на которых я проверяю очередную версию плагина. Как оно там внутри устроено мне, в прицнипе, даже не интересно. Мне главное, чтобы плагины подрядчика работали, работали быстро и не валились от каждого движения мышкой. Если на своих тестовых наборах я воспроизвожу какой-то баг, то сообщаю об этом подрядчику и даю так же этот набор, чтобы он мог баг воспроизвести и пофиксить.

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

Да и то, тестирую не я лично сам, а отдаю нашим тестеровщикам. Они это делают куда как лучше меня, а мне еще надо распределить задачи между разработчиками, составить список фич, спланировать, так что время для разработки у меня у самого почти не остается. А тут еще мегабайты кода читать.... Так я совсем никогда домой не попаду.

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

_O_>Крайне опытные способно аргументировано убедить начальство в своей правоте и саботировать процесс не будут.

Это если начальство способно убедиться. Обычно это не так. См. старую истину "я — начальник, ты — дурак". Я на своей шкуре познал "эффективных манагеров" и просто плюнул и ушел сам. Проекты в конторе загнулись. Один — по разработке — я забрал себе, заключив прямой договор с заказчиком. Второй в силу специфики забрать, увы, не могу. Контора сейчас от заказчика огребает по полной.