судя по комментариям, тема для вас больная — поделитесь своей историей. А мы и другие хабраюзеры будем учиться на вашем опыте.
Моя история состояла бы из нытья что «и так не работает и так не работает».
У меня куча вопросов, которые побуждают меня писать километры текста, но это слишком лениво.
Есть цели и задачи.
Менеджеры дают команды и получают обратную связь.
Программисты выдумывают абстракции и реализации, а так же кодят.
Менеджеры выдумывают какие то модели, некоторые вероятно полезные, некоторые нет.
Менеджеры отнимают время программистов, некоторое время отнимается с пользой, некоторое нет.
В какой то момент, менеджер решает что он главная производительная сила (это неизбежно если некому или нечему дать менеджеру по голове) и начинает нагружать программиста ерундой. Хотя наоборот, должен разгрузить производительную силу от посторонних вещей.
Ведь главное работа грузчика, а не контролера на выходе из склада, потому как грузчик делает работу которая приносит деньги.
Я не знаю никаких методик.
Если коллега устал и сидит за соседним монитором лазает по сайтам, нужно сказать уйди в другую комнату, не дизмораль.
Если сидит на стуле с закрытими глазами — уйди не дизмораль.
Если у кого то день рождения, нельзя что бы было слышно и видно тех кто отдыхает, смеется, пьет алкоголь и тд., выгнать всех подальше.
Если сам устал, уйди из рабочей комнаты, вообще не подходи к компьютерам, сходи на улицу если нет дождя.
Никогда не кодь больше 6 часов.
Даже если не устал, никогда не думай больше 6 часов, пойди лучше поболтай с аналитиком или менеджером или тестером или просто походи по офису, но не дизмораль тех кто работает.
Программист, не дергай коллег, если 20 минут не подумал над задачей сам.
Если 20 мин сидишь на месте и непонятна задача, пойди спроси у менеджера или аналитика, если непонятно как решать, тогда (после 20мин) спроси коллегу-программиста или собери группу программистов.
Менеджер, всегда регулярно напоминай о том что необходимо отчитаться о времени в тасктрекере, о том что надо писать документацию и писать тесты, как UI так и юнит.
Менеджер, всегда сам узнавай о ситуации с тасками, но не чаще чем 2 — 3 раза в день. Люди не мазохисты, они не будут регулярно делать сами что им неприятно, если со временем это не войдет в рефлексы и будет не требовать напряженной работы мозга.
В общем подобный список можно продолжать долго.
Менеджеры, на мой взгляд, не должны задалбывать людей ерундой, которая непосредственно не относится к их профессии.
Забавно, когда на показе заказчику, менеджеры сами не тыкают по UI и не рассказывают что да как, а переваливают показ на тестеров, а когда заказчик что то спрашивает, то вопрос переадресуют программисту, а не бизнес аналитику и менеджеру…
скорлупа ограничивающая сроки, бюджет и конечный результат проекта
это возможно лишь в случае когда «конечный результат проекта» подходит под «облезлую кошку», либо точь в точь уже делали подобный проект, что весьма не часто.
Остальное это наивная фантазия менеджера.
Смотрю я как то на ютубе очередное «как чото там делать „менеджеру“», в том случае тимлиду.
Тимлид одной известной компании говорит примерно следующее — «Со временем я стал настолько загружен, что пришлось какие то части своей работы переложить на программистов, что бы себя разгрузить».
У меня сразу мысль, а почему не нанять 2го, 3го тимлида, ведь если программистов загружать посторонними вещами, то проект будет замедлятся непропорционально быстро.
Так как множество, даже незначительных мелочей рассеивают внимание.
Вряд ли цель компании это «разгрузить тимлида», скорее «сделать/доработать проект» что бы приносил пользу.
Типичное жоп@-прикрывательство или путание интересов менеджера с интересами компании.
Рад за компанию, что нашла Егора, который закрыл все ошибки компании.
Только причем тут управление и интроверты?
Если строго регулярно требовать у подчиненных чего то, это войдет в привычку. Так создается культура.
Если требовать в течении двух недель, а потом забить, навык не закрепится.
Если требовать в течении 4х месяцев, то закрепится.
Например есть задача покрытия тестами и код ревью, если уже у всех разработчиков это в рефлексах (навык, культура), то новому разработчику они уже сами выставят требования по код ревью и тестам, без участия манагера. Да и то, придется время от времени подкреплять что культура не изменилась, что по прежнему это важно.
А до тех пор пока «требование» не закреплено в команде, обязанность менеджера заниматься этим самому.
Думаю вряд ли Петю тренировали с учетом кривой забывания.
Если кто-то — не может, не умеет и не желает узнать, как управлять людьми, то может просто плохой манагер?
А что важнее, работа Директора или программиста?
Может ну его нафиг вообще, зачем вам программист в компании?
Или пусть директор наймет того кто умеет «ладить» с программистом.
Так дети вообще сильно отличаются от родителей.
Просто для меня мысль забавная.
Я знаю заранее что получится продукт который в лучшем случае будет давать 10% угадываний, но все равно я разрабатываю этот продукт.
Что бы меня заставило это разрабатывать…
Мы только угадываем что подразумевается в статье, я даже не знаю что конкретно означает «слил задачу», да я даже не знаю что за задача была.
Дело в том что только конкретная ситуация дает конкретный ответ.
Абстракции, чем выше, тем больше дают допущений и непонятностей.
Предполагается что статья делится каким то опытом или знанием.
На мой взгляд, некоторые нюансы не проработаны.
Ситуация с Петей вымышленная (или нет), но прибавляет вес к Пункту А.
А я склоняюсь, что главное не правила, не пункты и переходы между ними, а взаимодействие между людьми.
Менеджеры всегда/часто портят взаимодействие людей, пытаясь управлять неуправляемым, используя тасктрекеры не для хранения тасков, а для естимейтов.
И вот что получается, если есть естимейт, то программист думает: «так надо успеть доделать, а не болтать, так как болтовня отнимает время, да болтовня полезна, но поскольку ввели KPI то надо подстроится под KPI.».
И несмотря на то что болтовня могла бы оставить Пете работу, если бы он сказал заранее что не успевает, он этого не делает, потому что KPI вынудили его поступать по другому.
Если менеджер решил строго относится к дедлайнам, то сам менеджер выключил коммуникацию.
Автор текста видимо сам об этом не подумал, раз в тексте такого нет.
Это вообще повсеместная ошибка менеджмента, звучит типа «когда вводим показатели, все перестают работать и генерируют показатели».
Классическое — «приветствуется работа в команде, помощь коллегам, обучение новичков», но если специально не заводятся под это таски, либо ставят строгие естимейты, то менеджеры сами выключают свои хотелки.
А когда пришёл дедлайн, Петя не успел. Объясниться не смог, потому что о любых «не успеваю» можно было предупредить заранее. Несмотря на провал, меняться и рассказывать про новые задачи Петя не хотел. Пришлось расстаться».
По вашему тут есть что то осмысленное? Слишком абстрактно, миллион ситуаций которые могут лежать под этими словами перекидывая ответственность туда сюда.
Во всех ситуациях виноват руководитель, и да, если нельзя управлять человеком то приходится увольнять. Но тема не раскрыта. Каждого с дедлайном увольнять?
Можете закапитанить этот абзац для меня?
На сайт можно было загрузить две фотографии, они смешивались, и выдавалась фотография ребенка, который получился бы у людей на фото.
Классная обманка, для тех кто не читал учебник биологии.
Получился бы, если бы геном состоял из одной хромосомы, и не существовало бы кроссинговера.
А так же если бы внешность зависела только от генов, что не так, так как однояйцевые близнецы похожи но не всегда идеально.
На моей практике и наблюдении за многочисленными коллегами на куче проектов, если появляется новый тип задачь для проекта, например появился тип Документ (class), а до этого, этого типа в проекте не было, то дедлайн случается как минимум в 30% — 50% случаях.
И дедлайн в 30% времени, наверное вообще нужно было бы считать что «успел».
Только один раз в моей карьере на проекте был человек который в разы умножал время которое мы думали нам нужно, не помню точно но пусть будет в 4 раза, и это был человек лучше всех остальных угадывающий время и то в 10% — 20% случаев сроки были нарушены, на 30% — 200% времени, да иногда по причине разморозки/пересмотра спецификации.
Так же, пример, уже есть в системе Документ, задача сделать Документ2, смотрю сколько времени потратил на прошлый Документ — 8 дней, думаю так ну подводных камней не будет, пишу в плане 5 дней. В итоге надрываясь делаю за 6 дней.
А нафига? Работать надо размеренно, я тогда, после, подумал, «блин ну поставил бы 7 дней или даже 8, зато бы не перенапрягся».
Сроки давят, может для физического труда это ничего страшного, но для умственного это вредно, выгораешь.
И я говорю не только лично про себя, а и про своих коллег.
У меня сформировалось мнение, что в общем то на сроки в разработке ПО видимо не стоит обращать серьезного внимания, есть задачи — это всего лишь road map, «копай» такси размеренно.
Вопрос к ВамFirstJohn, а как вы используете дедлайн в тасках? Для чего они менеджеру? Еще понятно когда на аутсорсе, нужно продавать время заказчику, ну так и продавай время, и не парься с дедлайнами, ты же коммуникабельный, убеди заказчика.
Но задача, с одной стороны, будет делаться столько сколько она занимает времени, а не столько, сколько указано в плане.
С другой стороны, если выделено два дня на то, где надо две недели, делаешь облезлую кошку, и заказчик получает не то что хотел, а то что оплатил за два дня.
То есть все равно платится за время, так в чем проблема дедлайна, если эта проблема не решаема в общем случае в разработке ПО?
В программировании в каких то случаях типичные задачи делаются быстро, а сколько делать нетипичные задачи, нельзя угадать.
Да я постоянно вижу стати как угадать время и всяком планинг покере, но в практике компаний где я работал, это не работало.
Объясниться не смог, потому что о любых «не успеваю» можно было предупредить заранее.
А какая вам разница? Вам нужно что бы было сделано, или вы из за своего ЧСВ (утрирую?) еще хотите что бы было сделано тогда, когда указанно в плане?
предупредить заранее
Насколько заранее? За час? А сколько таска делалась?
Несмотря на провал, меняться и рассказывать про новые задачи Петя не хотел.
Провал громкое слово, а может вам показалось?
Может Петя хотел менятся, только вот недокоммуникабельный менеджер/директор не смог объяснится что хочет от пети.
Мы же сторону Пети не услышим? ( и да, я не Петя, мне интересно про время и дедлайн)
Мы же не знаем чем Петя занимался, обучал нейронную сеть, у него было еще 1000 идей на 2 месяца вперед что подкрутить, что улучшить.
А что бы он Вам сказал? А Вы бы его поняли?
А Петя давно в отпуске был, может он за год утомился.
Может он планировал уйти, и вздохнул с облегчением или даже сделал так что бы его ушли?
Интересно, вы на каком языке пишите, со сборкой мусора? У вас между запросами от UI приложение умирает, или есть какое то «статическое» поле, которое содержит данные между запросами?
У вас случайно нет тяжелых структур в памяти которые приходится создавать/обновлять при каждом запросе?
Как вы поддерживаете иерархию итогов по счетам/субсчетам и по каталогу товаров с группами?
Немного позанудствую.
Разве так делают, а как на самом деле правильно делать проводки?
10 лет не в бухгалтерии, но вроде бы, сначала насчитывают долг, а потом по проводкам поступают «бумажные» денежки.
И вроде напрямую так не делают, а то если П1 дал деньгу В1, то получается что создался долг как будто В1 теперь должен П1, но ведь он не должен и не вернет никогда долг, проводки как то по другому принципу пишутся, через «вспомогательные» счета.
В одной известной бух. системе, Операция это Документ.
В одной Операции может быть несколько Проводок.
А для чего в вашей системе несколько Операций для одного Документа?
Может у вас Операция это всего лишь одна Проводка?
Понятно.
Дело в том что меня как раз интересуют всякие возможности учетных систем и для чего, в каких случаях, эти возможности применяются на практике.
Значит вы у себя задумали «возможность»-флаг «автоматически сворачивать сальдо».
Теперь мне бы еще узнать на каких счетах вы его включаете, а на каких выключаете, и зачем.
Если уже писали простите, длинный текст читаю бегло, если в нем обсуждают что то, что я уже долго не использовал.
мантиса — номер шага
в статье не увидел, почему записывают
3,14 = 1,57 *2 ( 2 в степени 1 равно 2, то есть экспонента 128-127 = 1)
вместо
3,14 = 3,14*1 (2 в степени 0 равно 1, то есть экспонента 127-127 = 0)
У меня куча вопросов, которые побуждают меня писать километры текста, но это слишком лениво.
Есть цели и задачи.
Менеджеры дают команды и получают обратную связь.
Программисты выдумывают абстракции и реализации, а так же кодят.
Менеджеры выдумывают какие то модели, некоторые вероятно полезные, некоторые нет.
Менеджеры отнимают время программистов, некоторое время отнимается с пользой, некоторое нет.
В какой то момент, менеджер решает что он главная производительная сила (это неизбежно если некому или нечему дать менеджеру по голове) и начинает нагружать программиста ерундой. Хотя наоборот, должен разгрузить производительную силу от посторонних вещей.
Ведь главное работа грузчика, а не контролера на выходе из склада, потому как грузчик делает работу которая приносит деньги.
Я не знаю никаких методик.
Если коллега устал и сидит за соседним монитором лазает по сайтам, нужно сказать уйди в другую комнату, не дизмораль.
Если сидит на стуле с закрытими глазами — уйди не дизмораль.
Если у кого то день рождения, нельзя что бы было слышно и видно тех кто отдыхает, смеется, пьет алкоголь и тд., выгнать всех подальше.
Если сам устал, уйди из рабочей комнаты, вообще не подходи к компьютерам, сходи на улицу если нет дождя.
Никогда не кодь больше 6 часов.
Даже если не устал, никогда не думай больше 6 часов, пойди лучше поболтай с аналитиком или менеджером или тестером или просто походи по офису, но не дизмораль тех кто работает.
Программист, не дергай коллег, если 20 минут не подумал над задачей сам.
Если 20 мин сидишь на месте и непонятна задача, пойди спроси у менеджера или аналитика, если непонятно как решать, тогда (после 20мин) спроси коллегу-программиста или собери группу программистов.
Менеджер, всегда регулярно напоминай о том что необходимо отчитаться о времени в тасктрекере, о том что надо писать документацию и писать тесты, как UI так и юнит.
Менеджер, всегда сам узнавай о ситуации с тасками, но не чаще чем 2 — 3 раза в день.
Люди не мазохисты, они не будут регулярно делать сами что им неприятно, если со временем это не войдет в рефлексы и будет не требовать напряженной работы мозга.
В общем подобный список можно продолжать долго.
Менеджеры, на мой взгляд, не должны задалбывать людей ерундой, которая непосредственно не относится к их профессии.
Забавно, когда на показе заказчику, менеджеры сами не тыкают по UI и не рассказывают что да как, а переваливают показ на тестеров, а когда заказчик что то спрашивает, то вопрос переадресуют программисту, а не бизнес аналитику и менеджеру…
это возможно лишь в случае когда «конечный результат проекта» подходит под «облезлую кошку», либо точь в точь уже делали подобный проект, что весьма не часто.
Остальное это наивная фантазия менеджера.
Тимлид одной известной компании говорит примерно следующее — «Со временем я стал настолько загружен, что пришлось какие то части своей работы переложить на программистов, что бы себя разгрузить».
У меня сразу мысль, а почему не нанять 2го, 3го тимлида, ведь если программистов загружать посторонними вещами, то проект будет замедлятся непропорционально быстро.
Так как множество, даже незначительных мелочей рассеивают внимание.
Вряд ли цель компании это «разгрузить тимлида», скорее «сделать/доработать проект» что бы приносил пользу.
Типичное жоп@-прикрывательство или путание интересов менеджера с интересами компании.
Рад за компанию, что нашла Егора, который закрыл все ошибки компании.
Только причем тут управление и интроверты?
Если требовать в течении двух недель, а потом забить, навык не закрепится.
Если требовать в течении 4х месяцев, то закрепится.
Например есть задача покрытия тестами и код ревью, если уже у всех разработчиков это в рефлексах (навык, культура), то новому разработчику они уже сами выставят требования по код ревью и тестам, без участия манагера. Да и то, придется время от времени подкреплять что культура не изменилась, что по прежнему это важно.
А до тех пор пока «требование» не закреплено в команде, обязанность менеджера заниматься этим самому.
Думаю вряд ли Петю тренировали с учетом кривой забывания.
Если кто-то — не может, не умеет и не желает узнать, как управлять людьми, то может просто плохой манагер?
А что важнее, работа Директора или программиста?
Может ну его нафиг вообще, зачем вам программист в компании?
Или пусть директор наймет того кто умеет «ладить» с программистом.
Мне думается что опять что то менеджеры себе напридумывали, работаьь не умеют — придумывают
Просто для меня мысль забавная.
Я знаю заранее что получится продукт который в лучшем случае будет давать 10% угадываний, но все равно я разрабатываю этот продукт.
Что бы меня заставило это разрабатывать…
Дело в том что только конкретная ситуация дает конкретный ответ.
Абстракции, чем выше, тем больше дают допущений и непонятностей.
Предполагается что статья делится каким то опытом или знанием.
На мой взгляд, некоторые нюансы не проработаны.
Ситуация с Петей вымышленная
(или нет), но прибавляет вес к Пункту А.А я склоняюсь, что главное не правила, не пункты и переходы между ними, а взаимодействие между людьми.
Менеджеры всегда/часто портят взаимодействие людей, пытаясь управлять неуправляемым, используя тасктрекеры не для хранения тасков, а для естимейтов.
И вот что получается, если есть естимейт, то программист думает: «так надо успеть доделать, а не болтать, так как болтовня отнимает время, да болтовня полезна, но поскольку ввели KPI то надо подстроится под KPI.».
И несмотря на то что болтовня могла бы оставить Пете работу, если бы он сказал заранее что не успевает, он этого не делает, потому что KPI вынудили его поступать по другому.
Если менеджер решил строго относится к дедлайнам, то сам менеджер выключил коммуникацию.
Автор текста видимо сам об этом не подумал, раз в тексте такого нет.
Это вообще повсеместная ошибка менеджмента, звучит типа «когда вводим показатели, все перестают работать и генерируют показатели».
Классическое — «приветствуется работа в команде, помощь коллегам, обучение новичков», но если специально не заводятся под это таски, либо ставят строгие естимейты, то менеджеры сами выключают свои хотелки.
Во всех ситуациях виноват руководитель, и да, если нельзя управлять человеком то приходится увольнять. Но тема не раскрыта. Каждого с дедлайном увольнять?
Можете закапитанить этот абзац для меня?
Получился бы, если бы геном состоял из одной хромосомы, и не существовало бы кроссинговера.
А так же если бы внешность зависела только от генов, что не так, так как однояйцевые близнецы похожи но не всегда идеально.
И дедлайн в 30% времени, наверное вообще нужно было бы считать что «успел».
Только один раз в моей карьере на проекте был человек который в разы умножал время которое мы думали нам нужно, не помню точно но пусть будет в 4 раза, и это был человек лучше всех остальных угадывающий время и то в 10% — 20% случаев сроки были нарушены, на 30% — 200% времени, да иногда по причине разморозки/пересмотра спецификации.
Так же, пример, уже есть в системе Документ, задача сделать Документ2, смотрю сколько времени потратил на прошлый Документ — 8 дней, думаю так ну подводных камней не будет, пишу в плане 5 дней. В итоге надрываясь делаю за 6 дней.
А нафига? Работать надо размеренно, я тогда, после, подумал, «блин ну поставил бы 7 дней или даже 8, зато бы не перенапрягся».
Сроки давят, может для физического труда это ничего страшного, но для умственного это вредно, выгораешь.
И я говорю не только лично про себя, а и про своих коллег.
У меня сформировалось мнение, что в общем то на сроки в разработке ПО видимо не стоит обращать серьезного внимания, есть задачи — это всего лишь road map, «копай» такси размеренно.
Вопрос к Вам FirstJohn, а как вы используете дедлайн в тасках? Для чего они менеджеру? Еще понятно когда на аутсорсе, нужно продавать время заказчику, ну так и продавай время, и не парься с дедлайнами, ты же коммуникабельный, убеди заказчика.
Но задача, с одной стороны, будет делаться столько сколько она занимает времени, а не столько, сколько указано в плане.
С другой стороны, если выделено два дня на то, где надо две недели, делаешь облезлую кошку, и заказчик получает не то что хотел, а то что оплатил за два дня.
То есть все равно платится за время, так в чем проблема дедлайна, если эта проблема не решаема в общем случае в разработке ПО?
В программировании в каких то случаях типичные задачи делаются быстро, а сколько делать нетипичные задачи, нельзя угадать.
Да я постоянно вижу стати как угадать время и всяком планинг покере, но в практике компаний где я работал, это не работало.
А какая вам разница? Вам нужно что бы было сделано, или вы из за своего ЧСВ
(утрирую?)еще хотите что бы было сделано тогда, когда указанно в плане?Насколько заранее? За час? А сколько таска делалась?
Провал громкое слово, а может вам показалось?
Может Петя хотел менятся, только вот недокоммуникабельный менеджер/директор не смог объяснится что хочет от пети.
Мы же сторону Пети не услышим? ( и да, я не Петя, мне интересно про время и дедлайн)
Мы же не знаем чем Петя занимался, обучал нейронную сеть, у него было еще 1000 идей на 2 месяца вперед что подкрутить, что улучшить.
А что бы он Вам сказал? А Вы бы его поняли?
А Петя давно в отпуске был, может он за год утомился.
Может он планировал уйти, и вздохнул с облегчением или даже сделал так что бы его ушли?
У вас случайно нет тяжелых структур в памяти которые приходится создавать/обновлять при каждом запросе?
Как вы поддерживаете иерархию итогов по счетам/субсчетам и по каталогу товаров с группами?
Разве так делают, а как на самом деле правильно делать проводки?
10 лет не в бухгалтерии, но вроде бы, сначала насчитывают долг, а потом по проводкам поступают «бумажные» денежки.
И вроде напрямую так не делают, а то если П1 дал деньгу В1, то получается что создался долг как будто В1 теперь должен П1, но ведь он не должен и не вернет никогда долг, проводки как то по другому принципу пишутся, через «вспомогательные» счета.
В одной Операции может быть несколько Проводок.
А для чего в вашей системе несколько Операций для одного Документа?
Может у вас Операция это всего лишь одна Проводка?
Дело в том что меня как раз интересуют всякие возможности учетных систем и для чего, в каких случаях, эти возможности применяются на практике.
Значит вы у себя задумали «возможность»-флаг «автоматически сворачивать сальдо».
Теперь мне бы еще узнать на каких счетах вы его включаете, а на каких выключаете, и зачем.
Если уже писали простите, длинный текст читаю бегло, если в нем обсуждают что то, что я уже долго не использовал.