К сожалению это так — победил не тот кто сделал лучший продукт, а тот кто сделал продукт быстрее или\и смог его побыстрее продать большему количеству людей.
С другой стороны в enterprise на мой взгляд уж очень тяжко все и медленно двигается. Народ может обсуждать и переделывать по 5 раз решение, хотя в это время в проде может быть абсолютная лажа, и любой из новых вариантов был бы лучше, но нет, надо же найти лучшее. В результате вместо 2х дней на изменение тратится от 2х до 3х недель. И это я говорю о простом изменении, если что-то помасшабнее, то вообще все грустно.
В общем во всем нужна мера.
Ой как раз первое приложение было финансовым, и там использовали тип с фиксированной точностью до 4 знаков, и много не было. Когда прочитала про float для финансовых данных аж все сжалось, это прямо «ужас ужас ужас».
Согласна про излишнюю универсальность. Тут очень важно уметь правильно остановится. Иногда решение усложняется в разы, потому что пытаются заложить универсальность, под случаи, которые происходят в 0,03% случаев и в итоге вся система работает медленнее и не если бы только медленнее, но и сложнее.
Очень важный момент, хорошо, что вы о нем написали. К сожалению есть люди, которые совсем не готовы ни с чем разбираться сами, и действительно спрашивают каждую запятую, при этом не ясно, если человек шел в проект без документации (я на собеседовании об этом старалась говорить) или с провалами в ней, то почему он не может прочитать и разобраться по коду. Фраза «Это слишком сложно» вообще убийственная, хорошо, что человек об этом говорит, это звоночек что ему нужно дать задачу попроще, но возникает вопрос, а будет ли это для него когда-нибудь понятно. В общем люди очень разные и уметь понять кому что давать и как — очень важный навык, который к сожалению нарабатывается небыстро.
Спасибо!
Про раскрытие темы — поняла, подумаю, напишу.
Озарение как и что нужно делать, чтобы правильно отдать задачу, у меня было после просмотра занятия про делегирование в школе Стратоплан, к сожалению не нашла у них в блоге соответствующую статью.
Из интересного и направляющего в эту сторону также есть Михаил Ефимович Литвак «Командовать или подчиняться», у него тоже описано как правильно делегировать задачи.
Вы правы, нельзя нанять джуниора и делегировать ему задачу по проектированию ядра системы например. Везде должна быть мера и здравый смысл. Идея в том, что сложность отдаваемых задач должна наращиваться постепенно.
Это как с мышцами, если есть тренер, который поднимает 100 кг и приду я, то я их не подниму как не делегируй. Но если я приду, мне тренер даст 3 кг, я с ними освоюсь и он не будет увеличивать нагрузку, то и результата будет немного, и я возможно расстроюсь и уйду к другому тренеру. Мне кажется так и с задачами и с ростом подчиненных. Должен быть определенный баланс между «как попасть в сроки», «сделать хорошо», и «прокачать людей». И последнее тоже не нужно забывать, ведь опять же никто из нас не пришел после универа супер профи, каждый человек растет благодаря обучению и решению более сложных задач.
Это очень важный момент — в идеале, если задача критичная, а та которую вы описали именно такая, она должна быть одобрена отличным разработчиком. То есть хороший может ею заниматься, но под контролем отличного как спеца.
Также если это вдруг какое то изменение в архитектуре, либо в каком то критичном узле — это не означает, что делать это может только отличный, и не может хороший, может. Но решение должно быть просмотрено, обсуждено и утверждено. И так же разделение на этапы — и подтверждение что на каждом этапе происходит то, что ожидалось — важно. Опять же code review — тоже в этом случае важный момент.
Кроме того надо глянуть, чем занят отличный разработчик и посмотреть нельзя ли что-нибудь у него забрать и передать кому нибудь еще, возможно так и время для такой важной задачи появится.
Есть вещи, где качеством нельзя жертвовать в угоду скорости, но их обычно немного. Если речь не идет о здоровье\безопасности людей, ну и о деньгах наверное.
О, это интересный вопрос и я немного подвисла, компания была совсем маленькая, и в общем была ситуация «если не я то кто», и уходить из компании тоже не хотелось — было очень интересно и работа горела, и прямо видение было. В общем из минусов только руководство, потом я поняла, что оно тоже плюс, главное уметь его правильно готовить.
Мне кажется, что человек примерно может оценить сколько времени он затратит на то или другое действие, если он примерно такую задачу уже делал. И да во время оценки он должен проверить что примерно нужно будет менять — прикинуть так сказать и набросать план действий. только после этого оценка будет близка к реальности.
К сожалению здесь обычно имеет место круговая порука — например клиент просит добавить что-то и договаривается об этом с руководством, и потом это приходит к менеджеру команды а затем к программисту. Естественно всем нужно знать «Когда это будет сделано» и вот тут если программист ошибается сильно со сроком, клиент начинает долбать руководство, оно менеджера, а он уже программиста. Мне кажется в этом случае схема с проактивностью хороша — чем раньше разработчик понимает, что не уложится в срок, тем раньше нужно сказать руководителю — ну и далее по иерархии.
К сожалению не всегда в компаниях на такие заявления сотрудников реагируют адекватно.
Написала коммент выше, что видимо неправильно донесла идею про ошибки и последствия.
Про пофигистов и людей, которые не заинтересованы в работе — это очень грустно, что есть народ, который готов реально «отсиживать» на работе за деньги. Ну то есть они же могут в это время что-то полезное делать, как то развиваться и расти. В общем печаль.
Про посыл понять, простить и отпустить. Нет, так не нужно делать. Немного повторю предыдущий коммент. Человек должен ощущать ответственность — и да, он должен исправлять, то что сделал криво. Но все это должно быть проговорено и объяснено до того как что-то случится. То есть у него в голове должно быть четкое понимание — например, что случится, если я залью неработающий код на production и уйду домой в пятницу. У него должна быть картина в голове — если это продуктовая компания, то она понесет вот такие то убытки, если заказчик, то он понесет убытки, а следом и компания. Должно быть проговорено, что в этом случае будет.
Опять же на мой взгляд схема, когда один человек может что-то залить и все сломать и уйти неверна. Нельзя, чтобы кто-то мог сломать систему — должен быть отлажен процесс. Он заливает, другой проверяет, и только если есть подтверждение, что все ок — можно уйти. Два человека ошибутся с меньшей вероятностью чем один.
Очень неприятны ситуации (я их наблюдала), когда на людей давят и просят сделать срочно, людей ночами делают, потом в этом срочно обязательно находится косяк, и на людей еще кричат\штрафуют\угрожают увольнением и пр. Мне кажется нужно понимать, что если человек что-то делает в спешке, оставаясь ночами на работе это все увеличивает вероятность ошибки, и значит руководитель согласен идти на такой риск и должен как то выстроить процесс так, чтобы отловить ошибки, ну или пересмотреть сроки того, что срочно.
Спасибо за пример, поняла, что несколько перегнула палку и неясно изложила идею. Пункт «Убивайте за ошибки» не означает, что человек не должен нести за них ответственность. Должен! Ведь, если мы освободим его от ответственности, то проблема только усилится. Вопрос в правильном балансе. Если перегнуть палку (как я описала в статье), то у человека формируется страх что-либо менять, он по 100 раз проверяет и получается тратит в разы больше времени, чем мог бы, кроме того он становится очень закрытым к каким либо новым подходам, которые могут дать выгоду, предпочитает делать «по накатанной» потому что так безопасно. Мне кажется в ИТ это скорее минусы, чем плюсы.
Про Ваш пример — на мой взгляд это скорее редкость. И от таких сотрудников безусловно нужно избавляться.
Про перевоспитание и возможность\невозможность делать свою работу. Тут все зависит как у вас с кадрами. Если можно повыбирать иногда проще действительно поменять человека. Я не очень люблю менять людей, ну только в крайних случаях.
Все еще зависит от специфики. Вот например в сервисной компании, в которой много небольших проектов, понятно что проще попрощаться с сотрудником, чем подстраиваться под него. Мой предыдущий проект был в продуктовой компании, с большим проектов, с недостатком документации — и там если человек уже разбирается в проекте, то лучше его сохранить и перевести на работу внутри отдела, которая ему больше подходит исходя из его специфики.
Если уж так хочется наказывать попробуйте вариант спросить человека как его нужно наказать. Вы удивитесь насколько обычно человек себя строже судит.
Но опять же я считаю, что этот метод неэффективным. Бывает, что человек не подходит для определенной работы — например внимательность у него недостаточная, его наказывай не наказывай он все равно будет ошибаться. Зато возможно в другом у него много плюсов.
В общем я верю, что каждый человек действует наилучшим способом, который видит\знает в данный момент. Ну и опять же вопросы к человеку «Как ты считаешь почему так случилось? Что мы могли бы сделать чтобы такого больше не происходило?» включают у человека анализ и повышают ответственность. А наказание, спущенное сверху, включает только защиту.
А как наказание помогает не совершать повторно ошибку?
Разве кто-то совершает ошибки специально?
На мой взгляд наказания не могут повысить внимание или повысить ответственность. Единственное, что могут усилить наказания — это страх, который, как следствие, затормозит процесс.
На мой взгляд важно проанализировать ситуацию и сделать выводы.
Вот например у большинства нет самоконтроля — значит контроль должен быть не само, а внешний.
То что сбоит по причине отсутствия внимания — можно добавить второго человека на просмотр, автоматизировать, написать тесты, нанять тестировщика, обязать тестировать разработчиков — если нет желания\денег нанят тестировщика. Есть много вариантов.
И после этого всего — люди все равно ошибаются. Вопрос в том, сколько этапов им надо пройти, чтобы эта ошибка попала на prod. Чем больше этапов, тем меньше вероятность, что ошибка не поймается, но возникают накладные расходы. И тут уже мы выбираем — вот эти накладные расходы мы можем оплатить и понести, а вот эти — нет. Но это сложный путь.
Упустила этот важный момент — спасибо, он крайне важен!
Именно защита своего коллектива — корректная это одна из важнейших на мой взгляд задач руководителя, иногда правильно и взять ответственность за ошибки своих подчиненных на себя. Так сказать прикрыть своим авторитетом.
Я считаю, что важно разделять жесткость осмысленную и бессмысленную. Руководитель должен уметь принимать непопулярные решения, также он должен выстроить правильные и помогающие работать процессы, для чего иногда тоже нужны жесткие меры.
Вопрос в том, что часто жесткостью и фразой «Я не должен быть популярным, я должен быть хорошим руководителем» прикрывают совершенно непрофессиональные и некрасивые вещи, такие как переход на личности и прочее. В любых отношениях — и в рабочих тоже, очень важно уважение, в принципе все эти пункты вообще не возникнут, если у руководителя будет чувство уважения к своим сотрудникам и понимание, что их труд и время ценно.
В принципе вместо статьи можно написать «уважайте своих сотрудников», но это достаточно общая фраза. Мне кажется каждый человек считает себя хорошим, и стремится стать лучше. И к сожалению некоторые руководители искренне считают себя очень хорошими и не видят иного способа работы — а их сотрудники при этом страдают от банального хамства. И вот иногда разделение общего принципа на достаточно очевидные части может помочь увидеть проблему.
Про вебинары и даже всякие тренинги про современные методы руководства — они, на мой взгляд полезны. Но проблема в основном в том, что за собой не видно. Это со стороны видны все ляпы, а когда ты в ситуации, кажется что ты Д'Артаньян. Поэтому полезны всякие наблюдения в реальности и хотя бы на крайний случай диктофон, или записывание ситуации, и ее анализ после.
Но редко же тренеров можно пригласить прямо в компанию, а тем более на внутреннее совещание. Бывает, что человек жалуется тренерам, что у него люди безинициативные, а сам же зарывает всю инициативу в зародыше, но не замечает за собой этого.
Однако, «дорогу осилит идущий», если человек учится, значит постепенно «пропитается» идеями и сможет воплотить их в своей практике.
Спасибо за важные дополнения.
Мне кажется очень важно, чтобы было понимание у человека что и для чего он делает. Что привело в возникновению этой задачи, потому что тогда он сможет подумать и возможно предложит лучшее решение, а возможно расширит то, что есть в постановке задачи.
Про контроль согласна. Грамотный контроль — это способ получить обратную связь и предоставить информацию наверх, сформировать видение как все идет и что сбоит. Не должно быть так называемого микроменеджмента — он обычно и раздражает.
Интересно, что обычно руководитель может вполне внятно объяснить почему стало не нужно, но почему-то это объяснение часто приходится вытягивать, а было бы здорово, если бы оно шло вместе со сменой курса.
А интересно как вы называете прямой прайс — просите доплатить за внеурочную работу? Или вы не в найме?
Значит мне везет на руководителей. Вообще хорошие руководители бывают, и особенно в ИТ. Конечно как описано у Ицхака Адизеса в «Идеальный руководитель» я не видела, но мне кажется это скорее из разряда «сферического коня в вакууме».
А можете дополнить список?
С другой стороны в enterprise на мой взгляд уж очень тяжко все и медленно двигается. Народ может обсуждать и переделывать по 5 раз решение, хотя в это время в проде может быть абсолютная лажа, и любой из новых вариантов был бы лучше, но нет, надо же найти лучшее. В результате вместо 2х дней на изменение тратится от 2х до 3х недель. И это я говорю о простом изменении, если что-то помасшабнее, то вообще все грустно.
В общем во всем нужна мера.
Согласна про излишнюю универсальность. Тут очень важно уметь правильно остановится. Иногда решение усложняется в разы, потому что пытаются заложить универсальность, под случаи, которые происходят в 0,03% случаев и в итоге вся система работает медленнее и не если бы только медленнее, но и сложнее.
Про раскрытие темы — поняла, подумаю, напишу.
Озарение как и что нужно делать, чтобы правильно отдать задачу, у меня было после просмотра занятия про делегирование в школе Стратоплан, к сожалению не нашла у них в блоге соответствующую статью.
Из интересного и направляющего в эту сторону также есть Михаил Ефимович Литвак «Командовать или подчиняться», у него тоже описано как правильно делегировать задачи.
Это как с мышцами, если есть тренер, который поднимает 100 кг и приду я, то я их не подниму как не делегируй. Но если я приду, мне тренер даст 3 кг, я с ними освоюсь и он не будет увеличивать нагрузку, то и результата будет немного, и я возможно расстроюсь и уйду к другому тренеру. Мне кажется так и с задачами и с ростом подчиненных. Должен быть определенный баланс между «как попасть в сроки», «сделать хорошо», и «прокачать людей». И последнее тоже не нужно забывать, ведь опять же никто из нас не пришел после универа супер профи, каждый человек растет благодаря обучению и решению более сложных задач.
Также если это вдруг какое то изменение в архитектуре, либо в каком то критичном узле — это не означает, что делать это может только отличный, и не может хороший, может. Но решение должно быть просмотрено, обсуждено и утверждено. И так же разделение на этапы — и подтверждение что на каждом этапе происходит то, что ожидалось — важно. Опять же code review — тоже в этом случае важный момент.
Кроме того надо глянуть, чем занят отличный разработчик и посмотреть нельзя ли что-нибудь у него забрать и передать кому нибудь еще, возможно так и время для такой важной задачи появится.
Есть вещи, где качеством нельзя жертвовать в угоду скорости, но их обычно немного. Если речь не идет о здоровье\безопасности людей, ну и о деньгах наверное.
К сожалению здесь обычно имеет место круговая порука — например клиент просит добавить что-то и договаривается об этом с руководством, и потом это приходит к менеджеру команды а затем к программисту. Естественно всем нужно знать «Когда это будет сделано» и вот тут если программист ошибается сильно со сроком, клиент начинает долбать руководство, оно менеджера, а он уже программиста. Мне кажется в этом случае схема с проактивностью хороша — чем раньше разработчик понимает, что не уложится в срок, тем раньше нужно сказать руководителю — ну и далее по иерархии.
К сожалению не всегда в компаниях на такие заявления сотрудников реагируют адекватно.
Про пофигистов и людей, которые не заинтересованы в работе — это очень грустно, что есть народ, который готов реально «отсиживать» на работе за деньги. Ну то есть они же могут в это время что-то полезное делать, как то развиваться и расти. В общем печаль.
Про посыл понять, простить и отпустить. Нет, так не нужно делать. Немного повторю предыдущий коммент. Человек должен ощущать ответственность — и да, он должен исправлять, то что сделал криво. Но все это должно быть проговорено и объяснено до того как что-то случится. То есть у него в голове должно быть четкое понимание — например, что случится, если я залью неработающий код на production и уйду домой в пятницу. У него должна быть картина в голове — если это продуктовая компания, то она понесет вот такие то убытки, если заказчик, то он понесет убытки, а следом и компания. Должно быть проговорено, что в этом случае будет.
Опять же на мой взгляд схема, когда один человек может что-то залить и все сломать и уйти неверна. Нельзя, чтобы кто-то мог сломать систему — должен быть отлажен процесс. Он заливает, другой проверяет, и только если есть подтверждение, что все ок — можно уйти. Два человека ошибутся с меньшей вероятностью чем один.
Очень неприятны ситуации (я их наблюдала), когда на людей давят и просят сделать срочно, людей ночами делают, потом в этом срочно обязательно находится косяк, и на людей еще кричат\штрафуют\угрожают увольнением и пр. Мне кажется нужно понимать, что если человек что-то делает в спешке, оставаясь ночами на работе это все увеличивает вероятность ошибки, и значит руководитель согласен идти на такой риск и должен как то выстроить процесс так, чтобы отловить ошибки, ну или пересмотреть сроки того, что срочно.
Про Ваш пример — на мой взгляд это скорее редкость. И от таких сотрудников безусловно нужно избавляться.
Про перевоспитание и возможность\невозможность делать свою работу. Тут все зависит как у вас с кадрами. Если можно повыбирать иногда проще действительно поменять человека. Я не очень люблю менять людей, ну только в крайних случаях.
Все еще зависит от специфики. Вот например в сервисной компании, в которой много небольших проектов, понятно что проще попрощаться с сотрудником, чем подстраиваться под него. Мой предыдущий проект был в продуктовой компании, с большим проектов, с недостатком документации — и там если человек уже разбирается в проекте, то лучше его сохранить и перевести на работу внутри отдела, которая ему больше подходит исходя из его специфики.
Но опять же я считаю, что этот метод неэффективным. Бывает, что человек не подходит для определенной работы — например внимательность у него недостаточная, его наказывай не наказывай он все равно будет ошибаться. Зато возможно в другом у него много плюсов.
В общем я верю, что каждый человек действует наилучшим способом, который видит\знает в данный момент. Ну и опять же вопросы к человеку «Как ты считаешь почему так случилось? Что мы могли бы сделать чтобы такого больше не происходило?» включают у человека анализ и повышают ответственность. А наказание, спущенное сверху, включает только защиту.
Разве кто-то совершает ошибки специально?
На мой взгляд наказания не могут повысить внимание или повысить ответственность. Единственное, что могут усилить наказания — это страх, который, как следствие, затормозит процесс.
На мой взгляд важно проанализировать ситуацию и сделать выводы.
Вот например у большинства нет самоконтроля — значит контроль должен быть не само, а внешний.
То что сбоит по причине отсутствия внимания — можно добавить второго человека на просмотр, автоматизировать, написать тесты, нанять тестировщика, обязать тестировать разработчиков — если нет желания\денег нанят тестировщика. Есть много вариантов.
И после этого всего — люди все равно ошибаются. Вопрос в том, сколько этапов им надо пройти, чтобы эта ошибка попала на prod. Чем больше этапов, тем меньше вероятность, что ошибка не поймается, но возникают накладные расходы. И тут уже мы выбираем — вот эти накладные расходы мы можем оплатить и понести, а вот эти — нет. Но это сложный путь.
Именно защита своего коллектива — корректная это одна из важнейших на мой взгляд задач руководителя, иногда правильно и взять ответственность за ошибки своих подчиненных на себя. Так сказать прикрыть своим авторитетом.
Вопрос в том, что часто жесткостью и фразой «Я не должен быть популярным, я должен быть хорошим руководителем» прикрывают совершенно непрофессиональные и некрасивые вещи, такие как переход на личности и прочее. В любых отношениях — и в рабочих тоже, очень важно уважение, в принципе все эти пункты вообще не возникнут, если у руководителя будет чувство уважения к своим сотрудникам и понимание, что их труд и время ценно.
В принципе вместо статьи можно написать «уважайте своих сотрудников», но это достаточно общая фраза. Мне кажется каждый человек считает себя хорошим, и стремится стать лучше. И к сожалению некоторые руководители искренне считают себя очень хорошими и не видят иного способа работы — а их сотрудники при этом страдают от банального хамства. И вот иногда разделение общего принципа на достаточно очевидные части может помочь увидеть проблему.
Но редко же тренеров можно пригласить прямо в компанию, а тем более на внутреннее совещание. Бывает, что человек жалуется тренерам, что у него люди безинициативные, а сам же зарывает всю инициативу в зародыше, но не замечает за собой этого.
Однако, «дорогу осилит идущий», если человек учится, значит постепенно «пропитается» идеями и сможет воплотить их в своей практике.
Мне кажется очень важно, чтобы было понимание у человека что и для чего он делает. Что привело в возникновению этой задачи, потому что тогда он сможет подумать и возможно предложит лучшее решение, а возможно расширит то, что есть в постановке задачи.
Интересно, что обычно руководитель может вполне внятно объяснить почему стало не нужно, но почему-то это объяснение часто приходится вытягивать, а было бы здорово, если бы оно шло вместе со сменой курса.
А интересно как вы называете прямой прайс — просите доплатить за внеурочную работу? Или вы не в найме?
Про «Спасибо» вроде бы мелочь, но приятная и важная.
А можете дополнить список?