Comments 44
Мне кажется, или в схеме вертикальная шкала инвертирована?
Экстраверт умеет и любит работать в команде. На раз-два налаживает контакты и генерирует идеи на лету.Рискую быть не оригинальным но несколько вопросов:
Интроверт продуктивен в тиши и одиночестве. Предпочитает общаться реже, лучше в чатике. Для идей ему нужно время, зато они будут взвешенными со всех сторон.
Экстраверт продуктивен в тиши и одиночестве, либо в шуме и толпе?
Экстраверт на раз-два налаживает контакты — а что значит налаживать контакты? Может экстраверту только показалось что он наладил контакт, а человек на против просто оказался вежливым?
Может два интроверта быстрее и прочнее установят контакт чем экстраверт с интровертом?
Экстраверт генерирует идеи на лету, и что, эти идеи просто выплеск бестолочи или идеи будут взвешенными со всех сторон?
Интроверт предпочитает общаться реже, лучше в чатике.Точно реже, может просто не в толпе, по крайней мере не в той толпе где все галдят, а в той где слушают и понимают? Речь об интровертах не аутистах же?
об интровертах не аутистахА я тут с удивлением узнал что я оказывается не интроверт, а мизантроп, но для экстравертов похоже мы все на одно лицо, «сидит как сыч, уткнулся в свой кудахтер».
Мы не стремились дать в статье подробное описание интровертов и экстравертов. Это сложный психологический вопрос. Задача статьи — рассказать про руководство интровертами. Все описание психотипов упрощены — мы обозначили главные отличия и показали их ярко.
Пункт А. Любой новый сотрудник находится здесь. У него есть минимальный запас доверияНа картинке наоборот, максимальный уровень доверия.
Несмотря на провал, меняться и рассказывать про новые задачи Петя не хотел. Пришлось расстатьсяменяться это пассивный залог? Вопрос, а «Таня, директор по маркетингу» как то меняла программиста, сообщила что ожидает?
Что выгоднее сменить программиста на нового или немного (?) изменить конкретного программиста?
Была ли от Тани обратная связь? Если нет, то Таня интроверт?
На картинке наоборот, максимальный уровень доверия.
Спасибо, поправили.
меняться это пассивный залог? Вопрос, а «Таня, директор по маркетингу» как то меняла программиста, сообщила что ожидает?
Конечно, Таня сообщила, что ждёт от Пети более подробных отчетов. В этом и был основной конфликт — “… рассказывать про новые задачи Петя не хотел”.
Что выгоднее сменить программиста на нового или немного (?) изменить конкретного программиста?
Безусловно, если человек готов меняться, нужно работать с ним.
Егор показал результат — доказал, что он крутой специалист, и Таня стала ему доверять. С доверием появилась и прозрачность. Теперь ему достаточно было описать работу в общих чертах, и Таня знала, что он занят делом.Мне кажется или Егор сделал работу Тани, зачем Таню держат на фирме?
Если Егор решил одну бизнес область на отлично, означает ли это что Егор специалист? Специалист в программировании или в той области в которой непонятно что делает Таня?
Вопросы похожи на тролинг, но все таки я хочу понять для себя прав я или нет.
Проблема прозрачности — почему менеджеру не выпытать у программиста всё что можно? Что еще за проблема прозрачности.
Похоже, Егор тот человек, которому в конце-концов могли-бы дать все задачи в компании (в рамках компетенции отдела) и он бы сосредоточил всё в своих руках. А дальше известны исходы.
Мне кажется или Егор сделал работу Тани, зачем Таню держат на фирме?
Если Егор решил одну бизнес область на отлично, означает ли это что Егор специалист? Специалист в программировании или в той области в которой непонятно что делает Таня?
Егор решил проблему в своей компетенции, показал, что он специалист в своей области. У Тани другие компетенции, но как руководитель она должна контролировать Егора.
Проблема прозрачности — почему менеджеру не выпытать у программиста всё что можно? Что еще за проблема прозрачности.
Выпытывать, чем занят сотрудник, — не вариант. Само слово “выпытывать” об этом говорит. Даже если отвлечься от его негативной окраски, построить работу отдела на выпытывании не эффективно.
Работа руководителя заключается не только в контроле за подчиненными. Уделять много времени выпытыванию — тратить его в пустую.
Если строго регулярно требовать у подчиненных чего то, это войдет в привычку. Так создается культура.
Если требовать в течении двух недель, а потом забить, навык не закрепится.
Если требовать в течении 4х месяцев, то закрепится.
Например есть задача покрытия тестами и код ревью, если уже у всех разработчиков это в рефлексах (навык, культура), то новому разработчику они уже сами выставят требования по код ревью и тестам, без участия манагера. Да и то, придется время от времени подкреплять что культура не изменилась, что по прежнему это важно.
А до тех пор пока «требование» не закреплено в команде, обязанность менеджера заниматься этим самому.
Думаю вряд ли Петю тренировали с учетом кривой забывания.
Если кто-то — не может, не умеет и не желает узнать, как управлять людьми, то может просто плохой манагер?
А что важнее, работа Директора или программиста?
Может ну его нафиг вообще, зачем вам программист в компании?
Или пусть директор наймет того кто умеет «ладить» с программистом.
Если требовать в течении двух недель, а потом забить, навык не закрепится.
Если требовать в течении 4х месяцев, то закрепится.
Например есть задача покрытия тестами и код ревью, если уже у всех разработчиков это в рефлексах (навык, культура), то новому разработчику они уже сами выставят требования по код ревью и тестам, без участия манагера. Да и то, придется время от времени подкреплять что культура не изменилась, что по прежнему это важно.
А до тех пор пока «требование» не закреплено в команде, обязанность менеджера заниматься этим самому.
Думаю вряд ли Петю тренировали с учетом кривой забывания.
Если кто-то — не может, не умеет и не желает узнать, как управлять людьми, то может просто плохой манагер?
А что важнее, работа Директора или программиста?
Может ну его нафиг вообще, зачем вам программист в компании?
Или пусть директор наймет того кто умеет «ладить» с программистом.
Про сроки отвечу вам одним комментарием.
Наш руководитель считает, что насильно заставить кого-то работать хорошо невозможно. Его задача не только контролировать, но и вдохновлять. И он знает, как воодушевить каждого сотрудника.
Дедлайны не вдохновляют, но совсем без сроков не обойтись. В маркетинге это особенно важно — рынок меняется быстро, и нужно успевать менять вместе с ним. Чтобы не срывать сроки и нервы сотрудникам, мы пользуемся “принципом яйца”.
Не увольняем и не убиваем за срыв сроков. Предусматриваем все возможные риски, определяем дедлайн, если не успеваем — перестраиваем процесс так, чтобы успеть. Петя не дал нам такой возможности — не предупредил, что не успевает.
Подробнее про принцип яйца можно прочесть здесь.
Наш руководитель считает, что насильно заставить кого-то работать хорошо невозможно. Его задача не только контролировать, но и вдохновлять. И он знает, как воодушевить каждого сотрудника.
Дедлайны не вдохновляют, но совсем без сроков не обойтись. В маркетинге это особенно важно — рынок меняется быстро, и нужно успевать менять вместе с ним. Чтобы не срывать сроки и нервы сотрудникам, мы пользуемся “принципом яйца”.
Не увольняем и не убиваем за срыв сроков. Предусматриваем все возможные риски, определяем дедлайн, если не успеваем — перестраиваем процесс так, чтобы успеть. Петя не дал нам такой возможности — не предупредил, что не успевает.
Подробнее про принцип яйца можно прочесть здесь.
Сотрудник долженЕсли почитать стати об интровертах, экстравертах и управлении, список чего должен сотрудник уйдет за сто пунктов.
Список из 100 пунктов, если он не написан «на бумажке», никогда никаким человеком исполнятся не будет.
Список из 100 пунктов написанный «на бумажке» будет отнимать 10сек*100 = 16 минут на каждый чих.
Мне кажется когда «управленец» говорит кому то что он «всегда должен помнить о», он переваливает свою ответственность на подчиненного.
Менеджеры, возможно по моему ошибочному мнению, существуют для того что бы со всеми общаться и работать вместо таймеров/будильников, а значит эта статья только отнимает время программистов.
А точно по вертикальной оси «Доверие» отметки «высокое» и «низкое» не перепутаны местами?
Каждый интроверт считает себя Егором, хотя чаще всего он обычный Петя ;)
А что не так с Петей, тема Пети не раскрыта вроде бы?
А вы точно читали статью?
А когда пришёл дедлайн, Петя не успел. Объясниться не смог, потому что о любых «не успеваю» можно было предупредить заранее. Несмотря на провал, меняться и рассказывать про новые задачи Петя не хотел. Пришлось расстаться».По вашему тут есть что то осмысленное? Слишком абстрактно, миллион ситуаций которые могут лежать под этими словами перекидывая ответственность туда сюда.
Во всех ситуациях виноват руководитель, и да, если нельзя управлять человеком то приходится увольнять. Но тема не раскрыта. Каждого с дедлайном увольнять?
Можете закапитанить этот абзац для меня?
Никто и не отрицал того, что тут многое недоговаривается, однако в контексте статьи подразумевается, что Петя «слил» задачу.
Мы только угадываем что подразумевается в статье, я даже не знаю что конкретно означает «слил задачу», да я даже не знаю что за задача была.
Дело в том что только конкретная ситуация дает конкретный ответ.
Абстракции, чем выше, тем больше дают допущений и непонятностей.
Предполагается что статья делится каким то опытом или знанием.
На мой взгляд, некоторые нюансы не проработаны.
Ситуация с Петей вымышленная(или нет), но прибавляет вес к Пункту А.
А я склоняюсь, что главное не правила, не пункты и переходы между ними, а взаимодействие между людьми.
Менеджеры всегда/часто портят взаимодействие людей, пытаясь управлять неуправляемым, используя тасктрекеры не для хранения тасков, а для естимейтов.
И вот что получается, если есть естимейт, то программист думает: «так надо успеть доделать, а не болтать, так как болтовня отнимает время, да болтовня полезна, но поскольку ввели KPI то надо подстроится под KPI.».
И несмотря на то что болтовня могла бы оставить Пете работу, если бы он сказал заранее что не успевает, он этого не делает, потому что KPI вынудили его поступать по другому.
Если менеджер решил строго относится к дедлайнам, то сам менеджер выключил коммуникацию.
Автор текста видимо сам об этом не подумал, раз в тексте такого нет.
Это вообще повсеместная ошибка менеджмента, звучит типа «когда вводим показатели, все перестают работать и генерируют показатели».
Классическое — «приветствуется работа в команде, помощь коллегам, обучение новичков», но если специально не заводятся под это таски, либо ставят строгие естимейты, то менеджеры сами выключают свои хотелки.
Дело в том что только конкретная ситуация дает конкретный ответ.
Абстракции, чем выше, тем больше дают допущений и непонятностей.
Предполагается что статья делится каким то опытом или знанием.
На мой взгляд, некоторые нюансы не проработаны.
Ситуация с Петей вымышленная
А я склоняюсь, что главное не правила, не пункты и переходы между ними, а взаимодействие между людьми.
Менеджеры всегда/часто портят взаимодействие людей, пытаясь управлять неуправляемым, используя тасктрекеры не для хранения тасков, а для естимейтов.
И вот что получается, если есть естимейт, то программист думает: «так надо успеть доделать, а не болтать, так как болтовня отнимает время, да болтовня полезна, но поскольку ввели KPI то надо подстроится под KPI.».
И несмотря на то что болтовня могла бы оставить Пете работу, если бы он сказал заранее что не успевает, он этого не делает, потому что KPI вынудили его поступать по другому.
Если менеджер решил строго относится к дедлайнам, то сам менеджер выключил коммуникацию.
Автор текста видимо сам об этом не подумал, раз в тексте такого нет.
Это вообще повсеместная ошибка менеджмента, звучит типа «когда вводим показатели, все перестают работать и генерируют показатели».
Классическое — «приветствуется работа в команде, помощь коллегам, обучение новичков», но если специально не заводятся под это таски, либо ставят строгие естимейты, то менеджеры сами выключают свои хотелки.
о любых «не успеваю» можно было предупредить заранее.И что бы изменилось? Прикрылась бы жопа менеджера, но такс все равно был бы на том же месте.
Ваши вопросы в разных комментах пересекаются, поэтому отвечу тут сразу на все.
Наш руководитель — стратег. Он разбирается во всех компетенциях отдела, поэтому может четко ставить задачи. Но он не погружается в компетенции глубоко — так, чтобы знать тонкости программирования, как Петя, и seo/аналитики/контекста, как Егор. Для этого есть специалисты.
Если специалист новый, руководитель, конечно, видит, чем он занят в целом. Какую задачу поставили — такую сотрудник и делает. Например, Петя был занят разработкой сайта. Но тонкостей работы сотрудника руководитель не знает. Рассказывать о них бессмысленно — вы правы. Но отпустить работу отдела на самотёк руководитель тоже не может. Мы решаем эту проблему с помощью матрицы доверия/прозрачности.
Наш руководитель объясняет сотруднику суть матрицы. Объясняет зачем нужны более подробные обсуждения задач на первом этапе работы — чтобы установить доверительные отношения. После пары недель/месяцев таких обсуждений руководителю достаточно кратких отчетов: делаю это, на таком этапе, все ок или такой-то затык — закончу задачу позже.
История с Петей действительно наш фейл. Но не только наш, потому что задача построить доверительные отношения — общая для руководителя и подчиненного. Наш просчёт был в том, что Таня показала Пете матрицу доверия, но не объяснила, что он либо идёт ей навстречу и рассказывает о задачах, либо не работает в нашем отделе. Петин просчёт был в том, что он самонадеянно решил — мы должны любить его просто так, и без отчетов. Возможно, если бы в итоге он показал результат, ему бы все простили. Однако Петя не успел и не предупредил — подставил себя, своего руководителя и целую команду, которая работала над проектом.
Сравнение историй Пети и Егора показательно. Оба заняты работой, в тонкостях которой руководитель не разбирается. Оба не хотят (не могут в силу интроверсии) давать подробных отчетов. В чем разница? Егор со скрипом, но давал эти отчеты, а Петя отказался наотрез. Егор показал результат, а Петя нет. Плюс Петя даже после фейла отказался рассказывать про задачи. Получается Петя — тот самый неуправляемый сотрудник, о котором вы говорите. Мы не стали допускать ошибку всех менеджеров — пытаться им управлять.
Varim, судя по комментариям, тема для вас больная — поделитесь своей историей. А мы и другие хабраюзеры будем учиться на вашем опыте.
Наш руководитель — стратег. Он разбирается во всех компетенциях отдела, поэтому может четко ставить задачи. Но он не погружается в компетенции глубоко — так, чтобы знать тонкости программирования, как Петя, и seo/аналитики/контекста, как Егор. Для этого есть специалисты.
Если специалист новый, руководитель, конечно, видит, чем он занят в целом. Какую задачу поставили — такую сотрудник и делает. Например, Петя был занят разработкой сайта. Но тонкостей работы сотрудника руководитель не знает. Рассказывать о них бессмысленно — вы правы. Но отпустить работу отдела на самотёк руководитель тоже не может. Мы решаем эту проблему с помощью матрицы доверия/прозрачности.
Наш руководитель объясняет сотруднику суть матрицы. Объясняет зачем нужны более подробные обсуждения задач на первом этапе работы — чтобы установить доверительные отношения. После пары недель/месяцев таких обсуждений руководителю достаточно кратких отчетов: делаю это, на таком этапе, все ок или такой-то затык — закончу задачу позже.
История с Петей действительно наш фейл. Но не только наш, потому что задача построить доверительные отношения — общая для руководителя и подчиненного. Наш просчёт был в том, что Таня показала Пете матрицу доверия, но не объяснила, что он либо идёт ей навстречу и рассказывает о задачах, либо не работает в нашем отделе. Петин просчёт был в том, что он самонадеянно решил — мы должны любить его просто так, и без отчетов. Возможно, если бы в итоге он показал результат, ему бы все простили. Однако Петя не успел и не предупредил — подставил себя, своего руководителя и целую команду, которая работала над проектом.
Сравнение историй Пети и Егора показательно. Оба заняты работой, в тонкостях которой руководитель не разбирается. Оба не хотят (не могут в силу интроверсии) давать подробных отчетов. В чем разница? Егор со скрипом, но давал эти отчеты, а Петя отказался наотрез. Егор показал результат, а Петя нет. Плюс Петя даже после фейла отказался рассказывать про задачи. Получается Петя — тот самый неуправляемый сотрудник, о котором вы говорите. Мы не стали допускать ошибку всех менеджеров — пытаться им управлять.
Varim, судя по комментариям, тема для вас больная — поделитесь своей историей. А мы и другие хабраюзеры будем учиться на вашем опыте.
судя по комментариям, тема для вас больная — поделитесь своей историей. А мы и другие хабраюзеры будем учиться на вашем опыте.Моя история состояла бы из нытья что «и так не работает и так не работает».
У меня куча вопросов, которые побуждают меня писать километры текста, но это слишком лениво.
Есть цели и задачи.
Менеджеры дают команды и получают обратную связь.
Программисты выдумывают абстракции и реализации, а так же кодят.
Менеджеры выдумывают какие то модели, некоторые вероятно полезные, некоторые нет.
Менеджеры отнимают время программистов, некоторое время отнимается с пользой, некоторое нет.
В какой то момент, менеджер решает что он главная производительная сила (это неизбежно если некому или нечему дать менеджеру по голове) и начинает нагружать программиста ерундой. Хотя наоборот, должен разгрузить производительную силу от посторонних вещей.
Ведь главное работа грузчика, а не контролера на выходе из склада, потому как грузчик делает работу которая приносит деньги.
Я не знаю никаких методик.
Если коллега устал и сидит за соседним монитором лазает по сайтам, нужно сказать уйди в другую комнату, не дизмораль.
Если сидит на стуле с закрытими глазами — уйди не дизмораль.
Если у кого то день рождения, нельзя что бы было слышно и видно тех кто отдыхает, смеется, пьет алкоголь и тд., выгнать всех подальше.
Если сам устал, уйди из рабочей комнаты, вообще не подходи к компьютерам, сходи на улицу если нет дождя.
Никогда не кодь больше 6 часов.
Даже если не устал, никогда не думай больше 6 часов, пойди лучше поболтай с аналитиком или менеджером или тестером или просто походи по офису, но не дизмораль тех кто работает.
Программист, не дергай коллег, если 20 минут не подумал над задачей сам.
Если 20 мин сидишь на месте и непонятна задача, пойди спроси у менеджера или аналитика, если непонятно как решать, тогда (после 20мин) спроси коллегу-программиста или собери группу программистов.
Менеджер, всегда регулярно напоминай о том что необходимо отчитаться о времени в тасктрекере, о том что надо писать документацию и писать тесты, как UI так и юнит.
Менеджер, всегда сам узнавай о ситуации с тасками, но не чаще чем 2 — 3 раза в день.
Люди не мазохисты, они не будут регулярно делать сами что им неприятно, если со временем это не войдет в рефлексы и будет не требовать напряженной работы мозга.
В общем подобный список можно продолжать долго.
Менеджеры, на мой взгляд, не должны задалбывать людей ерундой, которая непосредственно не относится к их профессии.
Забавно, когда на показе заказчику, менеджеры сами не тыкают по UI и не рассказывают что да как, а переваливают показ на тестеров, а когда заказчик что то спрашивает, то вопрос переадресуют программисту, а не бизнес аналитику и менеджеру…
скорлупа ограничивающая сроки, бюджет и конечный результат проектаэто возможно лишь в случае когда «конечный результат проекта» подходит под «облезлую кошку», либо точь в точь уже делали подобный проект, что весьма не часто.
Остальное это наивная фантазия менеджера.
бегло пробежал по треугольнику, да, это как раз когда решают что будет у кошки, пушистый хвост или наличие зубов.
Менеджеры выдумывают какие то модели, некоторые вероятно полезные, некоторые нет.
Менеджеры отнимают время программистов, некоторое время отнимается с пользой, некоторое нет.
В какой то момент, менеджер решает что он главная производительная сила (это неизбежно если некому или нечему дать менеджеру по голове) и начинает нагружать программиста ерундой. Хотя наоборот, должен разгрузить производительную силу от посторонних вещей.
Это очень интересное мнение. Я обсудил его с коллегами-программистами. Они рассказали, что работают примерно по тем заветам, которые вы описали. Но у нас топ-менеджмент не касается непосредственно работы сотрудника. Руководитель не лезет к программистам в
Пункт B. Повышение прозрачности — качественное развитие сотрудника.Это обязанность которого сотрудника, Пети или Тани?
Не настаиваю, но похоже что все таки повышение прозрачности, если такая задача поставлена, это задача менеджера.
Поскольку статья гласит что менеджер это коммуникабельный экстраверт, который отлично ладит с людьми и "На раз-два налаживает контакты и генерирует идеи на лету" то неужели это такая непосильная задача, для целого директора, сгенерировать план как продуктивно поговорить с Петей и убедить его что выгодно побольше тратить время на обсуждение Петиной работы, даже в ущерб самой работе, так как miscommunication может принести больше ущерба, по крайней мере по мнению менеджера.
И да, скорее всего не дело Пети решать на что тратить его купленное время, на кодинг или на обсуждение работы с коллегами.
Если закрыть глаза на КЗоТ, то конечно хочется увольнять непонятных тебе людей, но где программисты, а где КЗоТ.
Это обязанность которого сотрудника, Пети или Тани?
Повышение прозрачности — общая задача сотрудника и руководителя.
Вы правы, руководитель должен донести до сотрудника всю важность этой задачи. Однако если сотрудник не хочет слышать руководителя, встаёт диллема: расстаться, как с Петей, или отпустить контроль, как с Егором. Если сотрудник не потерял доверие руководителя (как Петя со своим фейлом) и при этом он ценный кадр (да-да, тут включаются циничные законы бизнеса) стоит попробовать отпустить контроль на одну задачу — чтобы он завоевал доверие через результат.
поговорить с Петей и убедить его что выгодно побольше тратить время на обсуждение Петиной работы, даже в ущерб самой работе, так как miscommunication может принести больше ущерба, по крайней мере по мнению менеджера.
Не соглашусь с вами про ущерб работе, ведь подробные обсуждения важны только на первом этапе (несколько рабочих недель/месяцев — зависит от ситуации). Они помогают повысить доверие руководителя, дальше достаточно кратких отчетов.
Теперь можно и в кабак — отличное место, чтобы познакомиться поближе. Пусть рассказ о себе начнут самые старые сотрудники. Пока дойдёте до новых, стеснения не останется.
Так «в кабак» или «в клуб анонимных алкоголиков»?
«Рассказы о себе» это какая-то нездоровая ерунда.
А что нездорового в рассказах о себе? Личное не выпытываем, о высоком начальстве не сплетничаем :) Обсуждаем интересы, делимся прошлым опытом работы.
Мы стремимся создать в отделе теплую дружескую атмосферу. Знаем, есть мнение, что работа должна оставаться работой. Но на наш взгляд работать с “незнакомцами” — так себе идея.
Мы стремимся создать в отделе теплую дружескую атмосферу. Знаем, есть мнение, что работа должна оставаться работой. Но на наш взгляд работать с “незнакомцами” — так себе идея.
UFO just landed and posted this here
А когда пришёл дедлайн, Петя не успел.На моей практике и наблюдении за многочисленными коллегами на куче проектов, если появляется новый тип задачь для проекта, например появился тип Документ (class), а до этого, этого типа в проекте не было, то дедлайн случается как минимум в 30% — 50% случаях.
И дедлайн в 30% времени, наверное вообще нужно было бы считать что «успел».
Только один раз в моей карьере на проекте был человек который в разы умножал время которое мы думали нам нужно, не помню точно но пусть будет в 4 раза, и это был человек лучше всех остальных угадывающий время и то в 10% — 20% случаев сроки были нарушены, на 30% — 200% времени, да иногда по причине разморозки/пересмотра спецификации.
Так же, пример, уже есть в системе Документ, задача сделать Документ2, смотрю сколько времени потратил на прошлый Документ — 8 дней, думаю так ну подводных камней не будет, пишу в плане 5 дней. В итоге надрываясь делаю за 6 дней.
А нафига? Работать надо размеренно, я тогда, после, подумал, «блин ну поставил бы 7 дней или даже 8, зато бы не перенапрягся».
Сроки давят, может для физического труда это ничего страшного, но для умственного это вредно, выгораешь.
И я говорю не только лично про себя, а и про своих коллег.
У меня сформировалось мнение, что в общем то на сроки в разработке ПО видимо не стоит обращать серьезного внимания, есть задачи — это всего лишь road map, «копай» такси размеренно.
Вопрос к Вам FirstJohn, а как вы используете дедлайн в тасках? Для чего они менеджеру? Еще понятно когда на аутсорсе, нужно продавать время заказчику, ну так и продавай время, и не парься с дедлайнами, ты же коммуникабельный, убеди заказчика.
Но задача, с одной стороны, будет делаться столько сколько она занимает времени, а не столько, сколько указано в плане.
С другой стороны, если выделено два дня на то, где надо две недели, делаешь облезлую кошку, и заказчик получает не то что хотел, а то что оплатил за два дня.
То есть все равно платится за время, так в чем проблема дедлайна, если эта проблема не решаема в общем случае в разработке ПО?
В программировании в каких то случаях типичные задачи делаются быстро, а сколько делать нетипичные задачи, нельзя угадать.
Да я постоянно вижу стати как угадать время и всяком планинг покере, но в практике компаний где я работал, это не работало.
Объясниться не смог, потому что о любых «не успеваю» можно было предупредить заранее.А какая вам разница? Вам нужно что бы было сделано, или вы из за своего ЧСВ
предупредить заранееНасколько заранее? За час? А сколько таска делалась?
Несмотря на провал, меняться и рассказывать про новые задачи Петя не хотел.Провал громкое слово, а может вам показалось?
Может Петя хотел менятся, только вот недокоммуникабельный менеджер/директор не смог объяснится что хочет от пети.
Мы же сторону Пети не услышим? ( и да, я не Петя, мне интересно про время и дедлайн)
Мы же не знаем чем Петя занимался, обучал нейронную сеть, у него было еще 1000 идей на 2 месяца вперед что подкрутить, что улучшить.
А что бы он Вам сказал? А Вы бы его поняли?
А Петя давно в отпуске был, может он за год утомился.
Может он планировал уйти, и вздохнул с облегчением или даже сделал так что бы его ушли?
Думаю, что вы все-таки «Петя». Иначе чего бы у вас так бомбило по его поводу, что половина комментов тут — ваши. ;)
Вам показалось, как про Петю, так и про бомбило.
Мне думается что опять что то менеджеры себе напридумывали, работаьь не умеют — придумывают
Мне думается что опять что то менеджеры себе напридумывали, работаьь не умеют — придумывают
Смотрю я как то на ютубе очередное «как чото там делать „менеджеру“», в том случае тимлиду.
Тимлид одной известной компании говорит примерно следующее — «Со временем я стал настолько загружен, что пришлось какие то части своей работы переложить на программистов, что бы себя разгрузить».
У меня сразу мысль, а почему не нанять 2го, 3го тимлида, ведь если программистов загружать посторонними вещами, то проект будет замедлятся непропорционально быстро.
Так как множество, даже незначительных мелочей рассеивают внимание.
Вряд ли цель компании это «разгрузить тимлида», скорее «сделать/доработать проект» что бы приносил пользу.
Типичное жоп@-прикрывательство или путание интересов менеджера с интересами компании.
Рад за компанию, что нашла Егора, который закрыл все ошибки компании.
Только причем тут управление и интроверты?
Тимлид одной известной компании говорит примерно следующее — «Со временем я стал настолько загружен, что пришлось какие то части своей работы переложить на программистов, что бы себя разгрузить».
У меня сразу мысль, а почему не нанять 2го, 3го тимлида, ведь если программистов загружать посторонними вещами, то проект будет замедлятся непропорционально быстро.
Так как множество, даже незначительных мелочей рассеивают внимание.
Вряд ли цель компании это «разгрузить тимлида», скорее «сделать/доработать проект» что бы приносил пользу.
Типичное жоп@-прикрывательство или путание интересов менеджера с интересами компании.
Рад за компанию, что нашла Егора, который закрыл все ошибки компании.
Только причем тут управление и интроверты?
Повысить прозрачность можно подробными обсуждениями задач, дополнительными вопросами руководителю и регулярными чек-инами.
Как правило, после подробных обсуждений и регулярных чек-инов начинается ад микроменеджмента и 7 пятниц на неделе, типа "как это не готово? как это я сам во вторник сказал всё переписать на технологию Б, до этого же вроде всё норм было?" и т.д.
Да, такое бывает, сам сталкивался. Но в FirstVDS мы стараемся не впадать в крайности: не допускаем ни бесполезной бюрократии, ни катастрофической бесконтрольности. Стараемся следовать принципу яйца, который тоже подглядели у Стратоплана:
“У проекта должна быть жесткая непробиваемая скорлупа ограничивающая сроки, бюджет и конечный результат проекта и жидкая гибко меняющаяся сердцевина. Вот эта скорлупа и должна быть обозначена в уставе. Внутренности будут формализоваться и меняться уже по ходу проекта”.
“У проекта должна быть жесткая непробиваемая скорлупа ограничивающая сроки, бюджет и конечный результат проекта и жидкая гибко меняющаяся сердцевина. Вот эта скорлупа и должна быть обозначена в уставе. Внутренности будут формализоваться и меняться уже по ходу проекта”.
Интроверты — застенчивы, молчаливы и замкнуты в своём мирке. Экстраверты дружелюбны, открыты, всегда готовы к общению.
Замечательное описание. Такое полное и беспристрастное. И ничего, что всегда говоря о замкнутости интровертов и о трудностях в общении с ними, никто не вспоминает о таком замечательном свойстве экстравертов как не замечать никого и ничего, кроме себя: обычное дело включить музыку на целый кабинет, что все коллеги синхронно надевают наушники или когда кто-то дебажить код ни с того ни с сего начать задавать всем глупые вопросы «Есть люди, которые против здоровой пищи?». Конечно, это же коммуникабельность и дружелюбие, а каждый, кто может подумать «Хочу послушать музыку, чтобы расслабится, но здесь люди работают — послушаю в наушниках», замкнутый социопат, с которым невозможно работать в команде.
Впечатление, что статью писал менеджер, который даже не стремился погрузиться в суть работы, которую он же должен организовывать. Посыл, как это интровертов привлекает разработка ПО, а не разработка ПО требует консентрации над поставленой задачей в течение длительного времени, чем фактически делает невозможным шумный отдых и активную жизнь по завершению рабочего дня, что усложняет попадание в данную сферу экстравертов.
По примеру с Таней и Егором. После длительных и бесполезных разговоров этот чудоруководитель пытался в свое время получить хотя бы какие-то базовые представления о специфике работы, которая в ее компетенции, так как данный работник — ее подчиненный? Потому что, получается, руководитель не понимает — это проблема работника, а не некомпетентность руководителя. Возможно Петя понял, что проводить ликбез — это не то, чего он хотел, учитывая то, что он его проводил екс-руководителю, а пришел новый, который не знает ничего из того, что знал предыдущий, хотя тот тоже был не слишком компетентным?
Замечательное описание. Такое полное и беспристрастное.
Обратите внимание на следующее предложение в тексте — “Это мнение обывателя”.
Впечатление, что статью писал менеджер, который даже не стремился погрузиться в суть работы, которую он же должен организовывать.
Статью писал такой же интроверт, может и не 100%-ый, но все же. И я совсем не руководитель, а рядовой сотрудник. Просто отношусь к теме интроверсии проще, зла на невнимательных экстравертов не держу. Считаю, что проблема тут не в психотипе, а в чуткости человека.
По примеру с Таней и Егором. После длительных и бесполезных разговоров этот чудоруководитель пытался в свое время получить хотя бы какие-то базовые представления о специфике работы, которая в ее компетенции, так как данный работник — ее подчиненный?
И работа Егора, и работа Пети действительно в компетенции Тани. Как и другие направления работы отдела. Однако Таня не погружена в программирование, seo, аналитику и контекст так глубоко, как специалисты, которые сосредоточены на одной-трех компетенциях. Для этого и существуют специалисты.
Таня знает работу Пети и Егора ровно настолько, чтобы чётко ставить задачи. Но не знает тонкости, знакомые специалисту, который десятилетиями прокачивает компетенцию.
Тани не нужен был ликбез, просто обратная связь. Поначалу более подробная, потом просто отчёт об этапе работы и сложностях (если есть).
Я думаю, что обязаловка даже экстравертов не влечет. Наигранность и фальшивость только отталкивают. Если все в коллективе подходят по человеческим качествам, то эти тим билдинги вообще не нужны.
Статья называется "Как руководить интровертами без вреда для здоровья". Типа это актуальная проблема.
Продуктивен, ответственен, другим не мешает.
И в чем проблема руководить таким человеком?
Может им просто не руководить надо, а помогать ему?
Я один здесь вижу безответственного чувака, балабола и бездельника?
Но что при этом думает РП-интроверт об продажнике-экстраверте, наобещавшем заказчику золотые горы, интроверт вслух не произносит, дабы не нарушать деловую этику и тонкую психику экстраверта.
Интроверт продуктивен в тиши и одиночестве.
Интроверт работает один и отвечает за всё сам.
Продуктивен, ответственен, другим не мешает.
И в чем проблема руководить таким человеком?
Может им просто не руководить надо, а помогать ему?
Экстраверт умеет и любит работать в команде. На раз-два налаживает контакты и генерирует идеи на лету.
Экстраверт привык делить и работу, и ответственность.
Я один здесь вижу безответственного чувака, балабола и бездельника?
Может вести крупный проект, где за коммуникацию будут отвечать экстраверты.
Но что при этом думает РП-интроверт об продажнике-экстраверте, наобещавшем заказчику золотые горы, интроверт вслух не произносит, дабы не нарушать деловую этику и тонкую психику экстраверта.
Sign up to leave a comment.
Как руководить интровертами без вреда для здоровья