Форум Сообщества Аналитиков
Дисциплины => Управление Проектом => Тема начата: Elf от 17 Июля 2012, 17:26:44
-
Ну все в теме..Только немного добавлю. Когда работала в разработке, менеджеры были в прошлом программистами, аналитиками, поэтому в процессе работы никогда не возникали непонимания. Сейчас менеджеры вообще не знакомы с разработкой, берут со специальностью "управление". И объяснить почему это столько надо разрабатывать, если "всего лишь надо сделать тоже самое, но в другой системе", мне трудно. Я трачу больше времени, что бы что -то объяснить менеджерам (их у меня аж 5!), заказчикам и т.д. Что делать, нервы на пределе...:((
-
Ну а в чём проблема?
1. Ваше время оплачивает работодатель
2. ПМам для лучшего управления проектом нужно понимать предмет, они это делают с вашей помощью
3. Вы опытный профессионал и находите ответы и объяснения
В теории — да, может. Выстраивая отношения с ключевыми экспертами проекта (например, вами) и прося пояснений, консультаций и обоснований по всем вопросам.
Большие проекты, программы, особенно госудраственные, так и делаются.
На практике такие универсальные ПМы редко встречаются и дорого стоят. Так складывается, что менеджерами становятся неуспешные инженеры.
-
К сожалению это так, только у этих "неуспешных" ЗП выше, чем у успешных инженеров.
А проблема в том, что у меня есть пул задач и сроки, а так как менеджеры не могут объяснить заказчикам, почему это так, то приходиться мне посещать всякие митинги и иметь дела с управляющими, договариваться с вендорами, чего я делать не хочу, да и времени тогда остается на выполнения плана совсем не много.
-
К сожалению это так, только у этих "неуспешных" ЗП выше, чем у успешных инженеров.
Не понял, к чему вы об этом. Да, небо синее, трава зелёная. Да, компании платят сообразно бюджету, за который отвечает человек, на какой объём денег он влияет.
А проблема в том, что у меня есть пул задач и сроки, а так как менеджеры не могут объяснить заказчикам, почему это так, то приходиться мне посещать всякие митинги и иметь дела с управляющими, договариваться с вендорами, чего я делать не хочу, ….
Ну так это же прекрасный вызов и область развития. Если раньше вы могли работали с планом просто на уровне потяну/не потяну, то теперь можете подробно рассчитывать составы и виды работ, включая работы по коммуникациям и обоснованиям своих решений.
-
«Времени для выполнения плана совсем немного».
Ну так сообщайте соответствующие риски своим руководителям, это их работа и ответственность с этими рисками работать. То, что профиль вашей загрузки изменился и потенциальная длительность работ увеличилось — это результат управленческого решения человека, который взял на работу ПМа без технических компетенций. Об этих последствиях своего решения он или знал или должен наконец узнать — например, от вас.
-
Да менеджеры только рады внести в проект трудозатраты по коммуникациям, только я не хочу. Ведь тогда меня будут тоскать на митинги на законных основаниях. А пока у меня есть отмазка. Вопрос даже не в том, что менеджеры не компетентны, вопрос в том, как не ходить на митинги, в который 90% времени тратиться в пустую. Я считаю, это работа менеджера. По крайней мере, когда я руководила проектами, я не могла позволить такую роскошь, что бы аналитик или программист сидели и "глазели" как бизнес между собой не может договориться.
-
… как не ходить на митинги, в который 90% времени тратиться в пустую. Я считаю, это работа менеджера.…
Т.е. вас заботит не то, что теряется общее время нескольких сотрудников компании, а конкретно вам неинтересно? :)
Ну вы же аналитик, проанализируйте, почему время теряется неэффективно (кстати, это только ваша точка зрения или менеджер тоже так считает?), предложите своему менеджеру альтернативный вариант.
-
Так складывается, что менеджерами становятся неуспешные инженеры.
Извиняюсь за оффтоп, но это достаточно спорный вопрос. Если рассматривать менеджера - именно ПМ, то мне видится как раз следующий путь развития: Программист -> аналитик -> ПМ. И первый переход не обязательно из-за неуспешности программирования.
-
Т.е. вас заботит не то, что теряется общее время нескольких сотрудников компании, а конкретно вам неинтересно? :)
Ну вы же аналитик, проанализируйте, почему время теряется неэффективно (кстати, это только ваша точка зрения или менеджер тоже так считает?), предложите своему менеджеру альтернативный вариант.
Мне - не эффективно. Потому мне нужен конечный результат обсуждения. Менеджер считает, что очень эффективно. т.к. что только с моим присутствием можно до чего нибудь договориться.
Да наверно, я ведь аналитик и должна понять. что проблема во мне...работа есть работа и если в организации так построено, то надо только под нее подстроиться. Хотелось бы пообщаться с тем, у кого такая же ситуация.
-
Извиняюсь за оффтоп, но это достаточно спорный вопрос. Если рассматривать менеджера - именно ПМ, то мне видится как раз следующий путь развития: Программист -> аналитик -> ПМ. И первый переход не обязательно из-за неуспешности программирования.
Это в идеале. А так обычно, программисты программипуют, аналитики анализируют, а манагеры руководят..Просто некоторые случайно стали программистами и наконец-то нашли свое русло-анализ и т.д.
-
Мне - не эффективно. Потому мне нужен конечный результат обсуждения. Менеджер считает, что очень эффективно. т.к. что только с моим присутствием можно до чего нибудь договориться.
Да наверно, я ведь аналитик и должна понять. что проблема во мне...работа есть работа и если в организации так построено, то надо только под нее подстроиться. Хотелось бы пообщаться с тем, у кого такая же ситуация.
Если корнем проблемы *для вас* является отсутствие у менеджера экспертизы в вашей работе, нельзя ли ему её как-то передать? Не в режиме — 2 вопроса/2 ответа, а более качественно?
-
можно, если бы это было интересно менеджеру. Обычно учишь кого угодно, при условии если это ему интересно. Просто, действительно не техническому спецу надо иметь огромное желание что бы во все это вникнуть. А если человек стал менеджером, то понятно что к усидчивости и к разбору задач обычно склонности не имеет.
-
Subj. Тяжело. Может, но это не ваш случай.
http://gaperton.livejournal.com/63100.html
-
наверно мой. Вообщем надо привыкать и подстраиваться. Успокаиваю себя тем, что будет страшнее если такой человек станет врачом. Лучше уж менеджером, а если своим языкам называть...администратор проекта.
-
Ни в коем случае не разделяю мнения, что у менеджера должен быть опыт работы рядовым программистом или сотрудником QA. Но умение управлять должно предполагать погружение в предметную область настолько, насколько это необходимо для принятия решений в зоне его (менеджера) ответственности. Если он не доверяет экспертам в оценке сложности той или иной задачи, то это просто плохой менеджер, а бэкграунд тут ни при чем.
Обязательность карьерного пути программист->аналитик->менеджер - брехня полная. Аналитики и программисты становятся менеджерами не потому, что так правильно, а потому что управлять некому.
-
Ни в коем случае не разделяю мнения, что у менеджера должен быть опыт работы рядовым программистом или сотрудником QA. Но умение управлять должно предполагать погружение в предметную область настолько, насколько это необходимо для принятия решений в зоне его (менеджера) ответственности.
Согласен.
Менеджер может успешно управлять проектом, не зная самого ПО.
Гораздо хуже обратное.
Когда "менеджер" знает только ПО, и думает что этого достаточно чтобы управлять проектом.
-
Я так поняла что можно управлять кому угодно и чем угодно. А вот, например, программировать кому угодно не получиться. Вся страна управляется "кухарками" и имеем, что имеем. Просто результат программиста виден сразу, а менеджера можно и не увидеть никогда.
Да нельзя управлять, не зная предметной области. Это плохой управленец и его управленцем язык не поворачивается назвать. Если ты хочешь управлять кем то хорошо, то сначала научись управлять собой и вникни в отрасль, которой управляешь!
-
Но умение управлять должно предполагать погружение в предметную область настолько, насколько это необходимо для принятия решений в зоне его (менеджера) ответственности.
Где же тогда взять критерии, по которым можно определить на сколько именно надо углубляться менеджеру в предметную область?
-
Да нельзя управлять, не зная предметной области. Это плохой управленец и его управленцем язык не поворачивается назвать.
А с каких пор качество управленца определяется знанием предметной области?
Ему что, надо знать как система работает с БД чтобы составить бюджет?
Ему надо знать особенности архитектуры чтобы опросить разработчиков на предмет трудозатрат и составить план-смету с продажником?
Ему надо владеть используемой в компании IDE чтобы планировать загрузку сотрудников на год с учетом проектов, больничных и отпусков?
Ему нужно уметь писать на Java чтобы поддерживать мотивацию команды и разруливать конфликты?
Знание предметной области это несомненно плюс и важно, но оно вторично по отношению к управлению.
-
Да...да...и да. А закладывать бюджет в 2 дня на перенос огромного функционала (из сотни таблиц) из одного вида системы в совсем в другой, оправдываясь тем, что только скопировать надо таблицы mssql в oracle, это правильно? И никак не понимая, почему нужен год, когда он сам может их ехселя в ворд перенести одним нажатим клавиши. И главное обнадеживать Заказчика. И потом может это и неправильно, я лично не могу себя заставить уважать манагера, который не разговаривает со мной на одном языке и стимула для выполнения его хрустальных планов не испытываю.
-
Ну тут же проблема не в предметной области, а в менеджменте.
Он НЕ СПРОСИЛ про трудоёмоксть и сроки. Это его ответственность и его жопа, пусть он и страдает — выговором, лишением премии, увольнением. Вы-то тут при чём? Это его проблема.
-
И потом может это и неправильно, я лично не могу себя заставить уважать манагера, который не разговаривает со мной на одном языке и стимула для выполнения его хрустальных планов не испытываю.
Значит он просто хреновый менеджер. Предметная область тут совсем не при чем.
-
Ну тут же проблема не в предметной области, а в менеджменте.
Он НЕ СПРОСИЛ про трудоёмоксть и сроки. Это его ответственность и его жопа, пусть он и страдает — выговором, лишением премии, увольнением. Вы-то тут при чём? Это его проблема.
Проблема моя. Когда менеджер заявляет, что 5 мин, а аналитик говорит год. Как-то Заказчик начинает косо смотреть на аналитика и считать его саботажником. Но в принципе, вы наверно правы, если бы был нормальный бизнес, а не по знакомству, то за такие решения отвечал бы менеджер, а не аналитик.
-
не знаю как у других, обычно у меня получается так, что сроки можно высчитать по формуле:
время которое сообщает разработчик надо умножить на 2. (это больше касается разработки электроники(разработка усложняется тем , что физические процессы не всегда очевидны + глюки софта в микроконтроллерах), в разработке ПО все намного точнее)
-
Вот с микроконтроллерами все проще. Таких проблем обычно у нас не возникало.
А вот при разработке сложных систем слушать разработку нельзя, у них на все "2 дня". Просто разработчик знает свой участок и н аего участке действительно два дня. А то что нужно еще согласовать со всеми кого это может коснуться, проштудировать все интегрированные системы, скоординировать изменение в разных системах и т.д.
-
Не сталкивалась с такими, поэтому просто не знаю.
Мне кажется, понимание предметной области упрощает задачу, но понять предметную область можно в среднем за полгода непрерывной работы в ней.
-
Можно вспомнить советских конструкторов - Глушко, Королева и многих других. Все они выросли из "разработческой" среды и потом ушли в управленцы. Видимо, в большинстве случаев они становились вполне удачными менеджерами. А можно вспомнить Чубайса - он является хорошим примером менеджера без понимания области в которой он ведет деятельность. Приватизация, энергетика, нанотехнологии - первая точно неудача, вторая - насколько я понимаю тоже к этому идет. Посмотрим что получится в третьей области!
-
Управленец не обязательно должен знать ПО, но он должен хорошо разбираться в процессе "Как именно достигать результата в айти проектах". Его функции грамотно поставить задачу, определить срок ее исполнения и проконтролировать результат.
Конечно, если управленец знает ПО, то ему легче выполнять свою работу.
Если не знает, то это его проблема, пусть находит людей. которые обладают нужными знаниями и на которых он может положиться, при решении вопросов в которых он "0". В любом случае за результат отвечает управленец. Если аналитик "накосячил", то виноват управленец. Варианты его ошибки: выбрал не того человека; поставил не правильную задачу; не правильно оценил сроки и пр.
Александр 3 не разбирался в деталях экономических теорий, был далек от проблем транспортных перевозок, но он разбирался в людях. В случайной встрече с Витте он разглядел его потенциал и предложил работу. А через некоторое время в России была проведена экономическая реформа и другие успешные проекты. По сути Александр 3 это аналогия управленца успешно управляющего проектом, без знания ПО.
-
Управленцем в данной ситуации был Витте, а Александр 3 только заказчиком. Говорите "грамотно ставить задачи", а как их ставить грамотно, если понятия не имеешь, что задача должна решать? Как определить срок, не зная задачи? А как узнать правильность решения?
-
Можно вспомнить советских конструкторов - Глушко, Королева и многих других. Все они выросли из "разработческой" среды и потом ушли в управленцы. Видимо, в большинстве случаев они становились вполне удачными менеджерами.
И Королев и Глушко не были менеджерами в том смысле, как мы понимаем это слово сейчас. Они были скорее "тим лидами", в то время как реальное управление осуществляло непосредственно советское руководство.
А можно вспомнить Чубайса - он является хорошим примером менеджера без понимания области в которой он ведет деятельность. Приватизация, энергетика, нанотехнологии - первая точно неудача, вторая - насколько я понимаю тоже к этому идет. Посмотрим что получится в третьей области!
Не могу согласиться. Чубайс очень талантливый менеджер, который блестяще достигал всех поставленных перед ним целей. Просто не мы с вами бенефициары его проектов, вот и все.
Управленцем в данной ситуации был Витте, а Александр 3 только заказчиком. Говорите "грамотно ставить задачи", а как их ставить грамотно, если понятия не имеешь, что задача должна решать? Как определить срок, не зная задачи? А как узнать правильность решения?
Александр III, например, грамотно ставил задачи, и он же, как заказчик знал что должна решить задача, и оценить результат.
А Витте соответственно отвечал за поиск и реализацию решения. Если говорить о тех же железных дорогах, то наверняка задачей было бесперебойное ж/д снабжение всей страны в соответствии с графиками движения. А национализация ж/д была способом решить эту задачу.
Но был ли Витте железнодорожником? Знал ли он как делать паровозные котлы? Вряд ли. Но при этом прекрасно справился.
В итоге наше обсуждение можно выродить к вопросу: Обязан ли начальник РЖД знать как делают паровозные котлы?
Имхо в такой постановке, ответ очевиднее чем изначально:)
-
Какое -то извращение пошло...Начальник железных дорог не выпускает паровые котлы. Вопрос тогда должен стоять так: должен ли директор завода знать как выпускаются котлы или Должен ли начальник ж/д знать в каких вагонах он перевозит груз и людей? Ответ тогда очевиден: ДА. ОБЯЗАН!
-
Как выпускаются котлы - обязан знать главный инженер.
Директору эти знания полезны и желательны, но не обязательны:)
-
Как выпускаются котлы - обязан знать главный инженер.
Директору эти знания полезны и желательны, но не обязательны:)
По Вашему принциму, тогда на должность директора завода вполне подойдет директор ресторана, главное подобрать Главного инженера. Только на практике я такое не видела
-
По Вашему принциму, тогда на должность директора завода вполне подойдет директор ресторана, главное подобрать Главного инженера. Только на практике я такое не видела
Это уже другая сфера работ. Ресторан - не производственная отрасль.
Однако, в истории страны были похожие примеры.
Например во время войны, хороших управленцев из кадрового резерва центрального аппарата ставки отправляли руководить заводами на местах, которые не справлялись с планом.
И в большинстве случаев они справлялись с задачей, т.к. именно в управлении превосходили местных директоров.
Так что на знании предметной области свет клином не сошелся. Это важно, но вторично.
-
Управленцем в данной ситуации был Витте, а Александр 3 только заказчиком.
Александр 3 управлял государством, а дальше по нисходящей Витте управлял той зоной которую ему выделили.
Но продолжаю ваш взгляд на работу, вы можете смело представить вашего менеджера внутренним заказчиком, а не управляющим проектом.
Как вы общаетесь с заказчиком? Наверное определяете границу вашего общения и способ (контракт, ТЗ).
Подойдите к общению с менеджером таким же способом - определите с ним границы и зоны ответственности. В некоторых компаниях эти зоны ответственности фиксируются во внутренних нормативных документах.
Если договориться не получается, по сформулируйте эти границы себе сами и менеджера просто ставьте перед фактом, что он не прав, когда залезает на вашу территорию (о том, что вы сформировали границы ему знать не обязательно). В тоже время если вы ждете от него активных действия в его зоне ответственности, не бойтесь требовать от него результата.
-
Это уже другая сфера работ. Ресторан - не производственная отрасль.
Однако, в истории страны были похожие примеры.
Например во время войны, хороших управленцев из кадрового резерва центрального аппарата ставки отправляли руководить заводами на местах, которые не справлялись с планом.
И в большинстве случаев они справлялись с задачей, т.к. именно в управлении превосходили местных директоров.
Так что на знании предметной области свет клином не сошелся. Это важно, но вторично.
Я знаю таких "присланных" менеджеров. К нам в банк прислали из бывших военных. Проект сдали действительно, только профессионалов в банке не осталось. Как-то и мне не хочется с такими работать.
-
Как вы общаетесь с заказчиком? Наверное определяете границу вашего общения и способ (контракт, ТЗ).
Подойдите к общению с менеджером таким же способом - определите с ним границы и зоны ответственности. В некоторых компаниях эти зоны ответственности фиксируются во внутренних нормативных документах.
Если договориться не получается, по сформулируйте эти границы себе сами и менеджера просто ставьте перед фактом, что он не прав, когда залезает на вашу территорию (о том, что вы сформировали границы ему знать не обязательно). В тоже время если вы ждете от него активных действия в его зоне ответственности, не бойтесь требовать от него результата.
Это конечно, правильная , открытая позиция. В компании по разработке даже "прокатывает". Но не в банке, если ты, конечно, не хочешь работать в данном банке последний день. Обычно, когда человек занимает такую позицию и совсем не хочет вникать в предметную область, то он не намерен слушать каких-то там подчиненных. Менеджер в разработке и менеджер в банке - разные должности.
-
Elf, не ограничивайте себя.
Банк или системный интегратор - какая разница.
Вы же аналитик и одна из задач этой профессии находить решения, в рамках существующих реалии. Отнеситесь к задаче творчески.
Если ваш менеджер настолько умен, начните говорить с ним языком технических терминов, и чем больше их будет тем лучше.
Этим вы дадите ему понять, какой он специалист в области it.
Дает неправильную задачу, запросите под ее выполнение информацию. Говорит нужно выполнить за 1 день, говорите конечно, но для этого нужно и далее по пунктам говорите, что вам конкретно нужно, чтобы выполнить за 1 день. Может быть жизнь окажется сказкой и он сразу предоставит все по вашему списку. А если не предоставит, то укажите точное время за сколько вы успеете выполнить каждый пункт списка. Вы же не отказываетесь выполнить работу за поставленный срок, просто еще нужно подготовиться к работе...
-
Господа, вернемся к определениям. Мы будем говорить о сотруднике у которого в трудовой "написано менеджер" или который "является менеджером"?
Давайте для начала определим эту разницу. Угу?
Чего настоящий то менеджер должен делать?
Кстати, можно еще взять модель PAIE Адизеса и рассмотреть ее.
-
Давайте спустимся с высот лидеров государств, директоров контор в 30 000 человек и прочих топов до уровня операционного менеджмента. Что там говорят великие? Что является первичной целью операционного менеджмента?
-
Давайте спустимся с высот лидеров государств, директоров контор в 30 000 человек и прочих топов до уровня операционного менеджмента. Что там говорят великие? Что является первичной целью операционного менеджмента?
уже и не знаю, что должен делать менеджер, но сегодня мне пришло письмо, что и планы проектов буду заполнять я, т.к. там есть "технические термины, в которых я могу ошибиться";))
-
Э. Голдратт:
"Улучшение потока [уменьшение Inventory] - это первичная задача операционного менеджмента".
Если некто не уменьшает Inventory, то он не выполняет основную задачу операционного менеджмента. Для уменьшения Inventory в проектах и процессах применяют различные методы. Определитесь с тем, рассматриваем мы проектного менеджера или процессного. И двинем дальше.
-
Э. Голдратт:
"Улучшение потока [уменьшение Inventory] - это первичная задача операционного менеджмента".
Если некто не уменьшает Inventory, то он не выполняет основную задачу операционного менеджмента. Для уменьшения Inventory в проектах и процессах применяют различные методы. Определитесь с тем, рассматриваем мы проектного менеджера или процессного. И двинем дальше.
Давайте определимся с понятием Inventory. Я бы предпочел говорить по-русски и использовать термины на русском.
-
Хочу все таки ответить на поставленный вопрос с учетом последних событий. Менеджер IT должен знать технические термины и вникать в тонкости технологий разработки. Понятно, что это трудно, но иначе никак.
Надо хотябы постоянно делать это. Потому что, если менеджер этого не делает, то теряет уважение у команды. Ну последствия вы представляете... У нас это произошло.
Правда, теперь другой перегиб, рассказывает как бы он разработал это в подробнотях. :) Ну думаю, скоро это у него пройдет, просто он хотел показать нам, что он такой же ка и мы...
-
Больная тема в нашем обществе.
Слушал пару лет назад интервью Рошаля, в котором он костил Голикову. По его словам министром здравоохранения должен быть в первую очередь врач, а во вторую менеджер. Т.е. более правильно, если врач переучится на менеджера, а не наоборот. Рошаль, кстати, упоминал и Глушко, и Королева, и всех министров здравоохранения (все, кроме Голиковой были ранее врачами).
На мой взгляд, управленец должен знать предметную область. Он ее, кстати, и будет изучать, хочет он этого или нет. Есть же устоявшееся мнение, что менеджер становится хорошим менеджером за 7 лет работы. Так что, Elf, надо просто подождать ))). А пока что "...и планы проектов буду заполнять я...".
Есть практика, когда управленец, не знающий предметку, работает в паре с techleader'ом (по сути, главным инженером), который отвечает только за технику. Управленец - за сроки, ресурсы и финансы.
Для управленца очень важно уметь вести людей за собой, обладать харизмой, и быть настоящим лидером.
Но бывают ситуации, обратные Вашей. Например, в моей конторе руководителем проекта, можно сказать всей разработки, назначили опытного программиста, по сути разработчика.
Он в IT понимает все на 100%, в предметной области заказчика тоже разбирается прилично. В итоге получился контроль и полное отсутствие делегирования задач.
Задачи валятся подробные, вплоть до "в такой-то таблице добавить такие-то записи". Так тоже работать не комфортно, хотя "работодатель оплачивает ваше время", люди не хотят работать винтиками.
Сложно в такой ситуации что-либо советовать. Возможно, нужно "подождать 7 лет", хотя какой МП работает столько на одном месте, у них ведь основная мотивация - карьерный рост.
Скорее всего, нужно поднимать вопрос перед руководством о роли techleader'а в дополнении к МП. Elf, ведь вы по сути выполняете эту роль, т.е. работаете "за того парня".
PS. Если руководство ситуацию не будет решать, то возможно проще уйти. Читал у одного известного человека цитату (не помню у кого), которая мне понравилась «Если вы по-настоящему любите свою работу, будьте готовы в любой момент попросить расчет». Основная идея - уметь отстаивать свою позицию.
-
Если мы говорим о небольших проектах, то безусловно ПМ должен совмещать две роли: знать техн сторону и уметь управлять.
В реальности на больших проектах работает пара (а м.б. и тройка): хороший управленец и техн лид.
Думаете Шойгу что-то понимает в ракетах и кораблях? Сомневаюсь, но, думаю, что у него все получится. И не надо ставить в пример бездарных управленцев ;)
-
В реальности количество больших проектов сильно меньше количества средних и малых проектов.
-
В реальности количество больших проектов сильно меньше количества средних и малых проектов.
Денис, ты становишься большевиком? ;)
-
Если мы говорим о небольших проектах, то безусловно ПМ должен совмещать две роли: знать техн сторону и уметь управлять.
В реальности на больших проектах работает пара (а м.б. и тройка): хороший управленец и техн лид.
Думаете Шойгу что-то понимает в ракетах и кораблях? Сомневаюсь, но, думаю, что у него все получится. И не надо ставить в пример бездарных управленцев ;)
Я не думаю, что Шойгу хороший пример - время покажет. Сегдюков для Пу тоже был отличным примером.
Я вот тут как раз нашла подтверждение своих мыслей.
http://www.stratoplan.ru/grandconf/career-in-software-company/
-
Сегдюков для Пу тоже был отличным примером.
А кто такой Сегдюков?
А Пу - это китаец?
-
А кто такой Сегдюков?
А Пу - это китаец?
http://www.utro.ru/articles/2013/02/21/1102776.shtml
-
А кто такой Сегдюков?
А Пу - это китаец?
Эд а что про Шойгу не спрсил? :)
-
Эд а что про Шойгу не спрсил? :)
А с ним-то что не так?