Доброго времени суток. Данный пост появился как ответ на этот пост, в котором описаны проблемы перехода к менеджеру среднего звена. На мой взгляд, подпись «из песочницы» отражает не только место, откуда попал этот пост на хабр, но и место работы автора. Раскрою свою мысль.
Для начала хотел бы уточнить, что я в свое время прошел путь от программиста до начальника, и побывал на различных постах. Может быть, моя правда обусловлена тем, что это всегда были небольшие коллективы и небольшие компании (с точки зрения количества сотрудников, а не с точки зрения оборотов). Потому могу предположить, что подобный короткий список родился только потому, что автор работает в крупной компании, где процесс восхождения более плавный и щадящий. Тем не менее, хочу отметить, что не все работают в мегакорпорациях — скорее наоборот.
Согласен — бида (ошибка в написании специальна). Тем не менее, проблема решаема, как автор справедливо указал в первой части, посредством кодинга. Свой проект, чужой — да пофигу, на самом деле, чей именно. Но вторая часть просто взбесила. Тот, кто сталкивался во время работы с заказчиком, который «я тоже кодил», меня поймет. Если работа, код, его стиль и написание не регламентированы четкими правилами, принятыми стандартами или внутренними распоряжениями компании — отойди от разработчика! Он не обязан писать код так, чтобы тебе нравилось (опять же ремарка — «ты» — обращение общее, а не направленное на конкретного автора). Он обязан писать код так, чтобы он работал. И все наши пристрастия и требования — всего лишь НАШЕ видение кода. А если это джуниор, у которого вы боитесь найти конструкцию вида:
id=0;
id++;
id++;
id++;
то за этим должен следить тот, кто к этому человеку преставлен, как начальник, но никак не тимлид.
И вновь автор под правильным заголовком пропихивает полную, извините, чушь. Попросить программиста на проект или денег на открытку имениннику — полная чушь по сравнению с тем, какие проблемы могут возникать реально. Пока ты программист, у тебя есть общение с тимлидом, кодом, ТЗ в качестве божьего помысла и изредка — с теми программистами, с которыми в силу фазы луны пересекся твой код. Когда в подчинении оказывается кучка людей — вот основная проблема. Варьируйте вектор в зависимости от того, общаетесь ли вы с заказчиком или нет.
Я написал код вот так. А я вот так. А у него не правильно. А это не я сломал. А дизайнер сошел с ума. А делать это 2 недели. А клал я на дедлайн через неделю. А архитектор ошибся. А тут надо было вот так. А БД не правильная. А давайте гуиды индексами.
Мало? Есть еще и заказчик.
А вот тут должно быть так. А тут вот этак. А мне наплевать на ТЗ. А я не подпишу акт. А я визуал, пока не увижу — не скажу, как оно должно работать. А вот тут нужно кнопочку. А мне плевать, что переписать пол проекта. А вы меня обманываете. А почему вы сразу не заложили, если теперь пол проекта переписать. И вообще, я 20 лет назад лабы на паскале писал, ща я научу вас работать.
Это, на мой взгляд, проблемы. Которые гораздо серьезней, чем подойти к директору за лишним полтинником тыщ на кооператив.
Вообще не понял, к чем этот пост. Как показывает практика, эта проблема всех. Ну вообще всех. На уровне программиста — это не успел оттестировать, написать, задеплоить, задокументировать и прочее. Эти проблемы — всегда и везде. Микро- и макро- менеджмент работают по схожим правилам. Если автор готов — могу поспорить на эту тему. И если такие проблемы возникли, то причин всего две — либо вопрос в структурировании процессов и подгонке их под уже работающую «успевать вовремя» концепцию, либо — понимания того, как это должно работать, не было вообще.
Пожалуй, единственное, с чем я не стал бы спорить. Нервов уходит прямо пропорционально сумме в зарплатной ведомости. Как сказал мне однажды один из начальников — «Чем больше денег, тем больше тараканов в коллективе».
Работа с документами. Это действительно становится проблемой, когда их размер скачкообразно увеличивается. Все ведь любят писать комменты, верно? Особенно к готовому коду? Каждый программист в душе смакует тот сладостный миг, когда ты начинаешь выполнять самое сложное и важное — писать комментарии к коду, который появился всего лишь за минуту работы, да подумаешь, левой пяткой в перерыве между кофе и сигаретой. Но хватит иронии — если даже документирование кода вызывает четкий рвотный рефлекс, то о чем говорить, когда подобной дребедени нужно писать на порядки больше.
Работа с коллективом. Уже описывал, но остановлюсь отдельно. Ты вдруг выныриваешь, и видишь, что вокруг — тоже программисты. И — о ужас! — они все пишут по-разному. Кто то решает задачу так, кто то иначе. Кто пишет кучу кода, лишь бы было красиво и элегантно, но при этом выполняет таск на 8 часов в течение 40, другой — решает задачу в лоб. Третий — кривопаттерный олигофрен, который вообще не знает, как правильно писать ПО, в отличие от великого гуру вас. Даже если это не транслировать в открытую, то один черт это лезет подспудно, как червячки. И с этим приходится бороться и душить в себе. Более того — все эти люди работают с разной скоростью. Которая при этом еще и зависит от внешних факторов. Которые, естественно, чушь.
Когда вы были программистами, такое объяснение, как не выспался, могло быть оправданием, причем существенным, вашей пониженной скорости работы. А когда вы стали руководителем — то какого покемона?! Разницу сложно понять и прочувствовать.
Хуже всего, когда вас бросает на уровень, в котором вы раньше не плавали. Писали бизнес-логику? А на-ка тебе дезигнера! Креатили гуя? Вот тебе работа с базами данных. И шнелле, шнелле! Время = деньги.
Ответственность за результат. Забудьте о том, что есть объяснение, почему не работает функция. Забудьте вообще, что есть функции. Есть продукт. Он либо работает, и вы молодец, почет, уважуха, и +2 печеньки к чаю, либо — не работает. Это понятно, что обосновать можно почти все, что угодно. Но первичен факт — в зоне ВАШЕЙ ответственности НЕТ результата. Прогресс есть, результата нет. Нужно менять парадигму мышления.
Работа с аутсорсом Несколько специфично, но тоже встречается повсеместно. Особенно крах — с фрилансерами. Вы будете, пусть и с опозданием, узнавать о проблемах на линии у провайдера в городе, в котором живет исполнитель, о нелетной погоде, о здоровье неизвестной вам доселе бабушке, а если повезет — о прекрасной незнакомке и не менее прекрасной ночи. Может, даже, с подробностями, но это на любителя. А еще вы узнаете, как учиться кодить самому на незнакомом языке за 2 часа, чтобы выполнить поставленную задачу.
Финансовый вопрос Тоже не для всех применимо, но все же. Вы познаете дзен балансирования между выдрессированным веками эволюции желанием нахапать в запасы побольше и физической расправой за нереальные бюджеты.
Проблема коллег С коллегами надо дружить. Ибо пиво, водка, колбаса — селедка. И вообще, атмосфера. И вообще — прикрой, я проспал. И если в этом же коллективе вы переходите в начальники, то сделать что то с этим коллективом будет крайне сложно. Сложно получать по башке за невыполненный код от того, кого ты вчера прикрывал перед таким же дурным, взбалмошным, некомпетентным, идиотским, бездарным начальством.
Если резюмировать — проблем может быть немало. Может и мой список для кого то покажется коротким. Да и мне он кажется коротким с точки зрения руководителя — у меня еще болтается куча факторов, о которых я бы мог рассказать. Но при этом это уже не задача руководителя среднего звена. Но то, что было написано в статье — это парниковые условия. Без вариантов. Реальность более жестокая, непредсказуемая, и самое главное — она полна людей. На которых и надо делать акцент. Все остальное — вторично.
Немного лирики
Для начала хотел бы уточнить, что я в свое время прошел путь от программиста до начальника, и побывал на различных постах. Может быть, моя правда обусловлена тем, что это всегда были небольшие коллективы и небольшие компании (с точки зрения количества сотрудников, а не с точки зрения оборотов). Потому могу предположить, что подобный короткий список родился только потому, что автор работает в крупной компании, где процесс восхождения более плавный и щадящий. Тем не менее, хочу отметить, что не все работают в мегакорпорациях — скорее наоборот.
Ремарки по посту автора
Я перестал творить
Согласен — бида (ошибка в написании специальна). Тем не менее, проблема решаема, как автор справедливо указал в первой части, посредством кодинга. Свой проект, чужой — да пофигу, на самом деле, чей именно. Но вторая часть просто взбесила. Тот, кто сталкивался во время работы с заказчиком, который «я тоже кодил», меня поймет. Если работа, код, его стиль и написание не регламентированы четкими правилами, принятыми стандартами или внутренними распоряжениями компании — отойди от разработчика! Он не обязан писать код так, чтобы тебе нравилось (опять же ремарка — «ты» — обращение общее, а не направленное на конкретного автора). Он обязан писать код так, чтобы он работал. И все наши пристрастия и требования — всего лишь НАШЕ видение кода. А если это джуниор, у которого вы боитесь найти конструкцию вида:
id=0;
id++;
id++;
id++;
то за этим должен следить тот, кто к этому человеку преставлен, как начальник, но никак не тимлид.
Общение с людьми
И вновь автор под правильным заголовком пропихивает полную, извините, чушь. Попросить программиста на проект или денег на открытку имениннику — полная чушь по сравнению с тем, какие проблемы могут возникать реально. Пока ты программист, у тебя есть общение с тимлидом, кодом, ТЗ в качестве божьего помысла и изредка — с теми программистами, с которыми в силу фазы луны пересекся твой код. Когда в подчинении оказывается кучка людей — вот основная проблема. Варьируйте вектор в зависимости от того, общаетесь ли вы с заказчиком или нет.
Я написал код вот так. А я вот так. А у него не правильно. А это не я сломал. А дизайнер сошел с ума. А делать это 2 недели. А клал я на дедлайн через неделю. А архитектор ошибся. А тут надо было вот так. А БД не правильная. А давайте гуиды индексами.
Мало? Есть еще и заказчик.
А вот тут должно быть так. А тут вот этак. А мне наплевать на ТЗ. А я не подпишу акт. А я визуал, пока не увижу — не скажу, как оно должно работать. А вот тут нужно кнопочку. А мне плевать, что переписать пол проекта. А вы меня обманываете. А почему вы сразу не заложили, если теперь пол проекта переписать. И вообще, я 20 лет назад лабы на паскале писал, ща я научу вас работать.
Это, на мой взгляд, проблемы. Которые гораздо серьезней, чем подойти к директору за лишним полтинником тыщ на кооператив.
Все успевать вовремя
Вообще не понял, к чем этот пост. Как показывает практика, эта проблема всех. Ну вообще всех. На уровне программиста — это не успел оттестировать, написать, задеплоить, задокументировать и прочее. Эти проблемы — всегда и везде. Микро- и макро- менеджмент работают по схожим правилам. Если автор готов — могу поспорить на эту тему. И если такие проблемы возникли, то причин всего две — либо вопрос в структурировании процессов и подгонке их под уже работающую «успевать вовремя» концепцию, либо — понимания того, как это должно работать, не было вообще.
Нервы
Пожалуй, единственное, с чем я не стал бы спорить. Нервов уходит прямо пропорционально сумме в зарплатной ведомости. Как сказал мне однажды один из начальников — «Чем больше денег, тем больше тараканов в коллективе».
Пропущено
Работа с документами. Это действительно становится проблемой, когда их размер скачкообразно увеличивается. Все ведь любят писать комменты, верно? Особенно к готовому коду? Каждый программист в душе смакует тот сладостный миг, когда ты начинаешь выполнять самое сложное и важное — писать комментарии к коду, который появился всего лишь за минуту работы, да подумаешь, левой пяткой в перерыве между кофе и сигаретой. Но хватит иронии — если даже документирование кода вызывает четкий рвотный рефлекс, то о чем говорить, когда подобной дребедени нужно писать на порядки больше.
Работа с коллективом. Уже описывал, но остановлюсь отдельно. Ты вдруг выныриваешь, и видишь, что вокруг — тоже программисты. И — о ужас! — они все пишут по-разному. Кто то решает задачу так, кто то иначе. Кто пишет кучу кода, лишь бы было красиво и элегантно, но при этом выполняет таск на 8 часов в течение 40, другой — решает задачу в лоб. Третий — кривопаттерный олигофрен, который вообще не знает, как правильно писать ПО, в отличие от великого гуру вас. Даже если это не транслировать в открытую, то один черт это лезет подспудно, как червячки. И с этим приходится бороться и душить в себе. Более того — все эти люди работают с разной скоростью. Которая при этом еще и зависит от внешних факторов. Которые, естественно, чушь.
Когда вы были программистами, такое объяснение, как не выспался, могло быть оправданием, причем существенным, вашей пониженной скорости работы. А когда вы стали руководителем — то какого покемона?! Разницу сложно понять и прочувствовать.
Хуже всего, когда вас бросает на уровень, в котором вы раньше не плавали. Писали бизнес-логику? А на-ка тебе дезигнера! Креатили гуя? Вот тебе работа с базами данных. И шнелле, шнелле! Время = деньги.
Ответственность за результат. Забудьте о том, что есть объяснение, почему не работает функция. Забудьте вообще, что есть функции. Есть продукт. Он либо работает, и вы молодец, почет, уважуха, и +2 печеньки к чаю, либо — не работает. Это понятно, что обосновать можно почти все, что угодно. Но первичен факт — в зоне ВАШЕЙ ответственности НЕТ результата. Прогресс есть, результата нет. Нужно менять парадигму мышления.
Работа с аутсорсом Несколько специфично, но тоже встречается повсеместно. Особенно крах — с фрилансерами. Вы будете, пусть и с опозданием, узнавать о проблемах на линии у провайдера в городе, в котором живет исполнитель, о нелетной погоде, о здоровье неизвестной вам доселе бабушке, а если повезет — о прекрасной незнакомке и не менее прекрасной ночи. Может, даже, с подробностями, но это на любителя. А еще вы узнаете, как учиться кодить самому на незнакомом языке за 2 часа, чтобы выполнить поставленную задачу.
Финансовый вопрос Тоже не для всех применимо, но все же. Вы познаете дзен балансирования между выдрессированным веками эволюции желанием нахапать в запасы побольше и физической расправой за нереальные бюджеты.
Проблема коллег С коллегами надо дружить. Ибо пиво, водка, колбаса — селедка. И вообще, атмосфера. И вообще — прикрой, я проспал. И если в этом же коллективе вы переходите в начальники, то сделать что то с этим коллективом будет крайне сложно. Сложно получать по башке за невыполненный код от того, кого ты вчера прикрывал перед таким же дурным, взбалмошным, некомпетентным, идиотским, бездарным начальством.
Если резюмировать — проблем может быть немало. Может и мой список для кого то покажется коротким. Да и мне он кажется коротким с точки зрения руководителя — у меня еще болтается куча факторов, о которых я бы мог рассказать. Но при этом это уже не задача руководителя среднего звена. Но то, что было написано в статье — это парниковые условия. Без вариантов. Реальность более жестокая, непредсказуемая, и самое главное — она полна людей. На которых и надо делать акцент. Все остальное — вторично.
