сегодня был очень короткий, очень насыщенный и очень суетный день. на прошлой неделе я получил-таки проект в продакшин-менеджмент. хорошо из этого лишь то, что я теперь с чистой совестью могу писать в резюме о том, что руководил проектом и командой из 7 человек. проект сей был признан кризисным еще зимой, тогда туда внедрили моего многоопытного коллегу М. для спасения утопающего. под этот же шумок получил "погоны" начальника отдела и я. надо отдать должное коллеге М. -- проект он вытянул и сдал почти в срок. два раза. теперь у него другой проект, более соотвествующие его профилю -- зная идею, я первый раз за всю свою 8милетнюю карьеру жалею, что ни дня не писал на .Net. зато вся кухня, связанная с описуемым проектом досталась мне. проблем много -- это и код, который писало очень много не очень добросовестных и очень спещащих людей, это и отсутсвие внятной технической документации по проекту, и использование различных фреймворков в стиле "из пушки по воробьям или щоб було"... но главная проблема -- тотальная расхлябанность и не мотивированность в команде.
собственно зимой не было и команды, были несколько человек, которые волею судеб занимались одним проектом. теперь есть команда, но это почему-то ситуацию не улучшило. люди по прежнему не заинтересованы в качественном выполнении поставленных задач. и если раньше они работали в условиях действительно заниженных сроков, теперь сроки приближены к реальным -- оценивают задачи либо непосредственно исполнители, либо экспертная группа. оценки исполнителей, как правило, ниже. но нет, желания соблюдать договоренности у команды не возникает. и это только девелопмент. есть еще тестинг.
с тестирование проекта есть только одна проблема -- он бесконечен. там нет объемов работ, которые необходимо проверить тестеру, чтобы одобрить разработку. там есть одна задача -- протестировать. в результате имеем количество багов, экспоненциально зависимых от часов, оставшихся до релиза -- чем ближе час деливери, тем больше поток багов, обнаруженных тестерами.
в итоге, сегодня я провел рабочий день, перемещаясь между разработчиками и тестерами, для того чтобы собрать, проконтролировать, напомнить, объяснить, решить, помочь...
нужно срочно внедрять процесс разработки. знать бы наверняка, как это делать правильно...
ужос какой. хотя и знакомо... удачи :)
ВідповістиВидалитиДа уж. Ну это логичный процесс. Я про расхлябанность команды. На рынке слишком много нас.
ВідповістиВидалитиКоманда которая не команда любой процесс превращает в отсутствие процесса. У нас в коллективе из 5 человек во время работы 1го недобросовестного разработчика так же работал весь коллектив. Все решилось только после его увольнения. Срок решения занял всего 1 неделю:)
ВідповістиВидалити2cotoha, это плод многомесячных усилий. хотя конечно да, ужас :)
ВідповістиВидалити2hiquest, а Вы себя к кому причисляете? к джуниорам-криворучкам, которые ни код нормально написать не могут, ни сделать что поручено? а почему так самокритично? таковых действительно хватает и даже более чем достаточно. а хороший сеньйор на вес золота. и я знаю этот вес :)
2major13, во-первых, это крайняя мера. во-вторых, мне некем этих заменить. да и носителями знаний были, есть и остаются именно эти разработчики. и команду мы склепали. пусть начерно, пусть стыки через один не ровные, но она есть. теперь осталось заставить ее работать. да и нет там слабого звена. или все слабые звенья.
2cotoha, а, ну да, спасибо. совсем я забыл хорошие манеры :)
ВідповістиВидалитиА вот не надо про джуниоров-криворучек - у нас по 5-7 лет люди "джуниоры", потому что руководство считает "оин не достигли уровня джедаев".
ВідповістиВидалитиА если серьезно - не, я, конечно, понимаю, 8 лет опыта все-таки немало, много бы отдал, чтобы его иметь, но на мой взгляд, разработчику с любым опытом в команде найдется место и работа - по силам и на пользу остальным.
Могу только посоветовать вам т.н. "тим-билдинг" - но не выезды на природу за город с тренером нажра.. поесть шашлыка :), а реально оценить способности и прикинуть, кто чем будет занимаццо далее - может быть, даже перетряхнуть команду.
P.S. Смею надеяться, что за непрошенный совет не пошлете куда подальше :)
2hiquest, Вы меня не правильно поняли. или я не совсем точно выразился, хотя мне кажется, что куда уж точнее. в любом случае вижу взаимонепонимаи и прошу меня извинить, поскольку в любом взаимонепонимании виноваты оба виз-а-ви.
ВідповістиВидалития совершенно не пытался Вас назвать джуниром-криворучкой. я просто спросил, к кому Вы сами себя относите. потому что много на рынке именно джуниров. причем совершенно разных джуниров. некоторые станут сеньйорами через два-три года, некоторые -- через полгода будут мидлами. а есть такие, которые станут мидлами только по выслуге лет и со сменой работы.
и тут дело не в "менедменте-которые-нифига-не-делает-а-получает-дохрена" (ТМ), а в критериях, которые отличают джуниора от мидла, а мидла от сеньйора. универсальных критериев нет, как нет прямых критериев. есть косвенные. и опыт -- только один из них, есть еще отвественность, есть еще самостоятельность. сеньйор-1 от мидла-3 отличается только стоимостью его управления.
что касается опыта, так он у Вас будет. через 5-6-8 лет у Вас его будет столько же, а то и больше. и он у Вас будет свой, а это намного лучше, чем получи Вы мой опыт :)
разумеется в команде всякому найдется место. по силам, по возможностям и по плечу. вопрос в другом -- люди не хотят на этом месте работать. нет, они настроены приносить пользу, понуро изображают из себя виноватых на статус-митингах. но бестолку -- все-равно мы опять и опять возвращаемся к разбору уже разобранных ошибок.
за совет спасибо. вобщем-то так мы и делаем. даст ли это свои плоды покажет время.
Антон, а кому-нибудь, кроме Вас, удобно читать на черном фоне белые буквы?
ВідповістиВидалити2CorWin: вообще-то я немного не hiquest, ну да ладно :)смысл понятен :)
ВідповістиВидалитиПо поводу повтора уже разобранных ошибок - вот это и есть действительно джуниорское.
Конкретно вам мог бы посоветовать вот что (надеюсь, вы уже что-нть подобное применяете).
Так вот, не секрет, что ценность каждого девелопера для проекта разная, т.е. варьируется от девелопера А к девелоперу Б, как бы обидно это ни звучало для всех.
Посему могу сказать вот так:
попробуйте разделить команду (логически) на 2 части. Первый "взвод" (костяк) включает наиболее вменяемых людей - в вашей ситуации это 2 человека + тех.лидер. Заранее следует их предупредить, что им придется выполнить до 80% всей предстоящей работы( позитивный фактор - работы не тупой, не обезьянней; однако, разумеется, материальная компенсация также обязательна).
"Костяк" занимается проектированием проекта, имплементацией того, что называется logic/service layer (наиболее ответственные участки), и - внимание - планированием рефакторинга существующего кода; да, это значительная дополнительная нагрузка, но см. предыдущий абзац. Остальные занимаются следующим: имплементят крупные вещи, проектируя мелкие (придется пойти на такой риск), и - без этого никак - распланированным рефакторингом.
Еще один, чисто управленческий момент, момент - такое деление должно быть только в вашей голове, не стоит как-то выделять костяк в остальных планах - например, при переписке и т.д. - это сильно демотивирует остальных; пусть они будут в курсе всего, что происходит с проектом, например; за любые попытки явно обрисовать кастовость - карать :)
Нам, вроде бы, помогло :) надеюсь, вам тоже
2Yuriy Drozdov, меня этот вопрос волнует меньше всего. Вам не удобно? почему мне кажется, что это не мои проблемы?
ВідповістиВидалитиЮрий, а теперь встречный вопрос, Вам не кажется, что Вы пришли со своим уставом в чужой монастырь? более того, в тот монастырь, куда Вас лично никто не звал?
2Meowth, спасибо за совет.
ВідповістиВидалитиоткровенно говоря такое деление было с самого начала. был один человек, который делал весь проект. потом к нему подключили других людей, которыми он стал управлять как тим лидер. собственно результаты такого управления мы и пытаемся разгрести. :)
а что касается разделения ролей, то они делятся естественным образом.в команде один сеньйор, два мидла (один из которых носит шапку сеньйора, но так случилось еще до меня) и один джуниор. вот двое сеньйоров и делают большинство работы. только тут тоже проблема в том, что реальный сеньйор ее таки делает, а вот второй... нет, тоже делает и тоже старается, но дергать приходится постоянно.
Да нет, я не обижаюсь. Не то что бы я так уж самокритичен, просто пытаюсь объективно смотреть на вещи. У меня еще просто нет достаточного опыта.
ВідповістиВидалитиofftop: А вы работали с лайфреем? Есть одна задачка, над которой я ломаю голову уже не один день.
2hiquest, работал. правда с 3.6.1 и 4.х версиями. но может быть буду чем-то полезен :)
ВідповістиВидалитиНУ вообщем голову я ломал над тем, как дать пользователю скачать файл. В конце концов написал отдельный сервлет и перенаправляю туда. Все работает, только после закачки портлет подвисает. Приходится жать F5. Вот не знаю даже, что с этим поделать...
ВідповістиВидалити2hiquest, а чем Вам стандартный способ не угодил? фалы статические? т.е. они имеют всегда одни и те же имена и хранятся в одном и том же месте? в таком случае смотрите как это сделано у самих Лайфреевцев. прелесть проекта в том, что они сами используют свой продукт. а не пишут Джава-портал, когда у самих сайт стоит на ПХП :)
ВідповістиВидалитиДа нет, файлы хранятся в базе. То есть приходится иметь дело с масивом байтов. Можно, конечно, сохраняить сначала файл на диск, но непонятно, когда тогда его удалять. Мне больше нравится решение через сервлет, но вот только портлет подвисает. Причем именно портлет, а не портал.
ВідповістиВидалити2hiquest, ну удалять можно поручить системе. пометив файл как темповый и сказав setDeleteOnExit(true). тогда как только пользователь закроет страницу, файл будет удален. воторой способ можно удалять вместе с сессией пользователя. сохранив массив генеренных файлов. это если с файлами.
ВідповістиВидалитиа если с потоком, то нужно респонсу поставить соотвествующий медиа-тип в заголовках. только нужно этот тип для портлетов разрешить иначе будет эксэпшин.
p.s. сорри за задержку, выходные.