Сначала действие, потом мотивация
Каждый из нас часто слышит фразы типа «Я бы ходил в спортзал, но у меня нет мотивации начать», «Я бы прошел эти курсы, но нет вдохновения», «Я бы освоил эту новую технологию, но не могу поймать настрой».
Мотивация -> действие
На мой взгляд, ждать откуда-то (непонятно откуда) сначала мотивацию/вдохновение, а потом начинать что-то реально делать – это не очень эффективная стратегия.
Да, иногда и правда приходит какой-то особый настрой, ты закатываешь рукава, делаешь дело, гуляешь смело.
Однако чаще всего этому душевному подъему неоткуда взяться, если ты еще ничего не начал. Ты в начале пути, твой результат нулевой, ты пока еще ничего не достиг. Откуда тут может появиться вдохновение?
Можно, конечно, черпать его из действий других, уже успешных в этом деле людей. Но давайте попробуем доставать его из своих успехов, а не из чужих.
Действие -> мотивация
Я призываю попробовать поменять причину и следствие местами. Сначала мы начинаем что-то делать, а потом появляется и соответствующий настрой.
Например, человек сделал волевое усилие, пошел в спортзал и начал «правильно» питаться. Он увидел спустя месяц в зеркале и на весах положительные результаты и – воооот она, мотивация.
Просыпается в нем, говорит ему: «Вот это успех! Ты сам его добился, ты это умеешь, ты можешь продолжать и дальше». Тогда человек окрылен сам своими достижениями, он сам хочет делать дело, не оглядываясь на других людей, не завися от них и не ища в них какое-то вдохновение.
Остается только вопрос о том, как что-то начать, если нет изначального волшебного пенделя в виде спустившегося сверху вдохновения?
Я не могу дать какой-то универсальный ответ, который бы подошел любому человеку. Для себя я выбрал ответы: усилие воли, дисциплина, стремление к осмысленным результатам.
Плюс отдельно стоит отметить силу привычки. Если сначала приходится себя заставлять делать что-то новое, то со временем деятельность входит в привычку и уже не требуется (или требуется, но меньше) дополнительных ментальных усилий на продолжение.
Итог
Не ждите знака от судьбы, пинка от начальника, понуканий от коллеги.
Просто начинайте делать и увидите, что вы реально можете, что у вас на самом деле получается, что вы правда молодец. И тогда дело пойдет бодро, весело и с удовольствием.
Каждый из нас часто слышит фразы типа «Я бы ходил в спортзал, но у меня нет мотивации начать», «Я бы прошел эти курсы, но нет вдохновения», «Я бы освоил эту новую технологию, но не могу поймать настрой».
Мотивация -> действие
На мой взгляд, ждать откуда-то (непонятно откуда) сначала мотивацию/вдохновение, а потом начинать что-то реально делать – это не очень эффективная стратегия.
Да, иногда и правда приходит какой-то особый настрой, ты закатываешь рукава, делаешь дело, гуляешь смело.
Однако чаще всего этому душевному подъему неоткуда взяться, если ты еще ничего не начал. Ты в начале пути, твой результат нулевой, ты пока еще ничего не достиг. Откуда тут может появиться вдохновение?
Можно, конечно, черпать его из действий других, уже успешных в этом деле людей. Но давайте попробуем доставать его из своих успехов, а не из чужих.
Действие -> мотивация
Я призываю попробовать поменять причину и следствие местами. Сначала мы начинаем что-то делать, а потом появляется и соответствующий настрой.
Например, человек сделал волевое усилие, пошел в спортзал и начал «правильно» питаться. Он увидел спустя месяц в зеркале и на весах положительные результаты и – воооот она, мотивация.
Просыпается в нем, говорит ему: «Вот это успех! Ты сам его добился, ты это умеешь, ты можешь продолжать и дальше». Тогда человек окрылен сам своими достижениями, он сам хочет делать дело, не оглядываясь на других людей, не завися от них и не ища в них какое-то вдохновение.
Остается только вопрос о том, как что-то начать, если нет изначального волшебного пенделя в виде спустившегося сверху вдохновения?
Я не могу дать какой-то универсальный ответ, который бы подошел любому человеку. Для себя я выбрал ответы: усилие воли, дисциплина, стремление к осмысленным результатам.
Плюс отдельно стоит отметить силу привычки. Если сначала приходится себя заставлять делать что-то новое, то со временем деятельность входит в привычку и уже не требуется (или требуется, но меньше) дополнительных ментальных усилий на продолжение.
Итог
Не ждите знака от судьбы, пинка от начальника, понуканий от коллеги.
Просто начинайте делать и увидите, что вы реально можете, что у вас на самом деле получается, что вы правда молодец. И тогда дело пойдет бодро, весело и с удовольствием.
На днях меня позвали в гости ребята из подкаста Цинковый прод https://znprod.io/
Для меня это было достаточно волнительно, потому что в телеграме или твиттере писать я конечно герой, а вот обсудить что-то вживую (когда нет времени подумать и отредактировать текст) на широкую аудиторию - это для меня был дебют.
Не буду оценивать качество того как оно получилось, но по своим ощущениям могу сказать что мне было интересно и я получил большое удовольствие.
Может быть вам будет интересно/полезно послушать/посмотреть:
вот аудио https://soundcloud.com/znprod/089-timlidstvo-tekhnicheskie-skily-zdorove-razgovor-s-evgeniem-antonovym
вот видео https://www.youtube.com/watch?v=Kby2hMiAEOM
Извините за слова паразиты, я волновался🙂
Для меня это было достаточно волнительно, потому что в телеграме или твиттере писать я конечно герой, а вот обсудить что-то вживую (когда нет времени подумать и отредактировать текст) на широкую аудиторию - это для меня был дебют.
Не буду оценивать качество того как оно получилось, но по своим ощущениям могу сказать что мне было интересно и я получил большое удовольствие.
Может быть вам будет интересно/полезно послушать/посмотреть:
вот аудио https://soundcloud.com/znprod/089-timlidstvo-tekhnicheskie-skily-zdorove-razgovor-s-evgeniem-antonovym
вот видео https://www.youtube.com/watch?v=Kby2hMiAEOM
Извините за слова паразиты, я волновался🙂
Обещал? Женись!
Как часто вам приходится сталкиваться с людьми, которые обещают что-то сделать, а потом сливаются? А еще не просто сливаются, а молча сливаются, будто бы ничего и не происходило. Будто бы не было разговоров и договоренностей.
Я периодически с такими сталкиваюсь во всех аспектах своей жизни. И лично мне искренне непонятно такое поведение.
Обещал
На мой взгляд, если ты что-то обещаешь кому-то, то надо своё обязательство выполнять.
Допустим, это я такой человек, что-то внутри меня мешает по-тихому сливаться с договоренностей. Может, это совесть, может, воспитание, может, еще что-то. Каждый человек индивидуален, и я не призываю ни в коем случае равняться на кого-то конкретного.
Тем не менее, если смотреть на объективные причины, то нужно выполнять свои обещания хотя бы для того, чтобы поддерживать репутацию надежного человека. Человека, с которым можно вести дела, на которого можно положиться, которому можно доверять. Лично мне, что в работе, что в личной жизни, больше хочется иметь дело с теми, кто держит своё слово и придерживается договоренностей.
Ну и в целом, надо исполнять договоренности, чтобы не прослыть мудаком, к которому пренебрежительно относятся, потому что он на словах Лев Толстой, а на деле – как повезет.
Не смог
Все мы люди, все делаем ошибки или просчеты. Никто не застрахован от вмешательства рандомных обстоятельств. Я это понимаю. Но не понимаю, когда человек просто молча пропадает, если что-то пошло не так. Хотя сам он тебе что-то наобещал, тебе приходится к нему идти, теребить его, слушать все эти вероятные и невероятные истории, почему не получилось-не срослось. А в отдельных случаях даже историй никаких нет, как и раскаяния.
Я сам попадаю в ситуации, когда не получается сделать то, что обещал. Но я всегда предупреждаю человека, если такое случается. Извиняюсь, предлагаю варианты, как можно поступить в этой ситуации.
Постеснялся, растерялась
Бывает, что на человека как-то морально давят и выжимают выгодные для себя обещания. Привет менеджерам и горящим(нет) срокам В этом случае я бы рекомендовал больше тренировать умение сохранять спокойствие в переговорах и говорить «нет», чем на всё подряд соглашаться, а потом страдать и пропадать.
Итог
Невыполнение своих обязательств я считаю неуважением по отношению к тому, кому ты это пообещал. Да, дело может сорваться сейчас. Но пропадать и делать вид, что ничего не случилось – очень стремная, на мой взгляд, тема.
Учитесь обдумывать то, что обещаете, делать, что обещали, нести ответственность за свои обязательства и уважать тех, кому вы эти обещания выдали. Тогда и люди к вам будут относиться более доверительно и уважительно.
Бонусный контент
Мы с Ярославом Астафьевым договорились написать пост на эту тему, каждый у себя в канале. Его вариант здесь https://t.me/Descended_Potentially/99. Я подозреваю, что у него будет несколько иная точка зрения, но это не точно
Как часто вам приходится сталкиваться с людьми, которые обещают что-то сделать, а потом сливаются? А еще не просто сливаются, а молча сливаются, будто бы ничего и не происходило. Будто бы не было разговоров и договоренностей.
Я периодически с такими сталкиваюсь во всех аспектах своей жизни. И лично мне искренне непонятно такое поведение.
Обещал
На мой взгляд, если ты что-то обещаешь кому-то, то надо своё обязательство выполнять.
Допустим, это я такой человек, что-то внутри меня мешает по-тихому сливаться с договоренностей. Может, это совесть, может, воспитание, может, еще что-то. Каждый человек индивидуален, и я не призываю ни в коем случае равняться на кого-то конкретного.
Тем не менее, если смотреть на объективные причины, то нужно выполнять свои обещания хотя бы для того, чтобы поддерживать репутацию надежного человека. Человека, с которым можно вести дела, на которого можно положиться, которому можно доверять. Лично мне, что в работе, что в личной жизни, больше хочется иметь дело с теми, кто держит своё слово и придерживается договоренностей.
Ну и в целом, надо исполнять договоренности, чтобы не прослыть мудаком, к которому пренебрежительно относятся, потому что он на словах Лев Толстой, а на деле – как повезет.
Не смог
Все мы люди, все делаем ошибки или просчеты. Никто не застрахован от вмешательства рандомных обстоятельств. Я это понимаю. Но не понимаю, когда человек просто молча пропадает, если что-то пошло не так. Хотя сам он тебе что-то наобещал, тебе приходится к нему идти, теребить его, слушать все эти вероятные и невероятные истории, почему не получилось-не срослось. А в отдельных случаях даже историй никаких нет, как и раскаяния.
Я сам попадаю в ситуации, когда не получается сделать то, что обещал. Но я всегда предупреждаю человека, если такое случается. Извиняюсь, предлагаю варианты, как можно поступить в этой ситуации.
Постеснялся, растерялась
Бывает, что на человека как-то морально давят и выжимают выгодные для себя обещания. Привет менеджерам и горящим(нет) срокам В этом случае я бы рекомендовал больше тренировать умение сохранять спокойствие в переговорах и говорить «нет», чем на всё подряд соглашаться, а потом страдать и пропадать.
Итог
Невыполнение своих обязательств я считаю неуважением по отношению к тому, кому ты это пообещал. Да, дело может сорваться сейчас. Но пропадать и делать вид, что ничего не случилось – очень стремная, на мой взгляд, тема.
Учитесь обдумывать то, что обещаете, делать, что обещали, нести ответственность за свои обязательства и уважать тех, кому вы эти обещания выдали. Тогда и люди к вам будут относиться более доверительно и уважительно.
Бонусный контент
Мы с Ярославом Астафьевым договорились написать пост на эту тему, каждый у себя в канале. Его вариант здесь https://t.me/Descended_Potentially/99. Я подозреваю, что у него будет несколько иная точка зрения, но это не точно
Матрица доверия и прозрачности
Установить доверие с заказчиком, руководством, командой – очень важно, если вы планируете работать вдолгую.
Один из хороших способов как это сделать, можно почерпнуть из матрицы доверия и прозрачности.
Довольно развернуто и с примерами можно прочитать много где, например, здесь https://habr.com/ru/company/stratoplan/blog/202028/
Не хочу читать! В чем суть?
Суть в том, что надо повышать прозрачность вашей работы.
Сначала к вам нет доверия и никто не знает, что вы из себя представляете. Вы начинаете явно и понятно показывать свою работу, уровень доверия начинает повышаться (если вы нормально работаете, конечно 🙂).
Потом, когда доверие уже выросло, а прозрачность еще высока, появляется очень важный переломный момент. Вас ждут два стула:
1. Вы снижаете прозрачность (потому что так несколько проще работать), но рискуете как-нибудь косякнуть, а разгневанная вторая сторона скажет: «Ага, что-то ты стал темнить и повылезали косяки». Тогда вы откатитесь в начальное состояние, где и понятности нет, и доверие потеряно.
2. Вы проявляете дисциплину, не расслабляетесь, не снижаете прозрачность своей работы и тогда уровень доверия держится крепче, даже в случае, если вы где-то прокосячили.
На какой стул садиться – выбирайте сами. Я люблю работать на долгосрочную перспективу, так что я выбираю второй.
Что за прозрачность? Это про что?
Это, например, многими нелюбимые отчеты, тасктрекеры, дэйли стендапы, ретроспективы, регулярные демо, мастер-классы и воркшопы по мотивам своей работы и прочие организационные дела, про которые говорят «это не нужно, это только отвлекает».
Правда отвлекает? Да.
Правда ли Билл Гейтс или Линус Торвальдс делали свои великие продукты (на начальном этапе, по крайней мере) без всех этих вещей? Да.
Правда ли, что вы не Билл Гейтс (даже после вакцинирования) и не Линус Торвальдс, а просто работник или руководитель в компании на много человек, где всё должно работать в едином страстном порыве, чтобы было хорошо? Скорее всего, да (но это не точно)
Зачем мне это ваше доверие? Я же программист, я ИНЖЕНЕР!!!
Задавайтесь этим вопросом каждый раз, когда будете предлагать какие-то ощутимые технические изменения в проект, или вести зарплатные переговоры. Ответ придет сам собой 🙂
Итог
Не ленитесь потратить чуточку времени на организационные процессы, связанные с повышением прозрачности вашей работы. Всё это окупится повышением доверия, а доверие уже можно сконвертировать во много других, более материальных вещей.
Установить доверие с заказчиком, руководством, командой – очень важно, если вы планируете работать вдолгую.
Один из хороших способов как это сделать, можно почерпнуть из матрицы доверия и прозрачности.
Довольно развернуто и с примерами можно прочитать много где, например, здесь https://habr.com/ru/company/stratoplan/blog/202028/
Не хочу читать! В чем суть?
Суть в том, что надо повышать прозрачность вашей работы.
Сначала к вам нет доверия и никто не знает, что вы из себя представляете. Вы начинаете явно и понятно показывать свою работу, уровень доверия начинает повышаться (если вы нормально работаете, конечно 🙂).
Потом, когда доверие уже выросло, а прозрачность еще высока, появляется очень важный переломный момент. Вас ждут два стула:
1. Вы снижаете прозрачность (потому что так несколько проще работать), но рискуете как-нибудь косякнуть, а разгневанная вторая сторона скажет: «Ага, что-то ты стал темнить и повылезали косяки». Тогда вы откатитесь в начальное состояние, где и понятности нет, и доверие потеряно.
2. Вы проявляете дисциплину, не расслабляетесь, не снижаете прозрачность своей работы и тогда уровень доверия держится крепче, даже в случае, если вы где-то прокосячили.
На какой стул садиться – выбирайте сами. Я люблю работать на долгосрочную перспективу, так что я выбираю второй.
Что за прозрачность? Это про что?
Это, например, многими нелюбимые отчеты, тасктрекеры, дэйли стендапы, ретроспективы, регулярные демо, мастер-классы и воркшопы по мотивам своей работы и прочие организационные дела, про которые говорят «это не нужно, это только отвлекает».
Правда отвлекает? Да.
Правда ли Билл Гейтс или Линус Торвальдс делали свои великие продукты (на начальном этапе, по крайней мере) без всех этих вещей? Да.
Правда ли, что вы не Билл Гейтс (даже после вакцинирования) и не Линус Торвальдс, а просто работник или руководитель в компании на много человек, где всё должно работать в едином страстном порыве, чтобы было хорошо? Скорее всего, да (но это не точно)
Зачем мне это ваше доверие? Я же программист, я ИНЖЕНЕР!!!
Задавайтесь этим вопросом каждый раз, когда будете предлагать какие-то ощутимые технические изменения в проект, или вести зарплатные переговоры. Ответ придет сам собой 🙂
Итог
Не ленитесь потратить чуточку времени на организационные процессы, связанные с повышением прозрачности вашей работы. Всё это окупится повышением доверия, а доверие уже можно сконвертировать во много других, более материальных вещей.
Золотой молоток
Золотой молоток — антипаттерн проектирования, заключающийся в использовании одного и того же решения везде, в том числе путём искусственной подгонки условий, требований, ограничений задачи под данное решение. Это уверенность в полной универсальности какого-либо решения и применение этого к любым задачам.
Сталкивались ли вы с подобным, или может быть сами страдаете чем-то таким? Не торопитесь отвечать быстро, порефлексируйте. Ответ может вас удивить.
Почему мы везде видим гвозди для нашего молоточка?
На мой взгляд есть две основные причины: успешный опыт и ограниченный кругозор.
У нас за плечами уже есть какой-то успешный опыт реализации проектов. И если в этом опыте фигурирует один и тот же инструмент, технология, подход, то нам начинает казаться, что мы открыли универсальную методику и заодно абсолютную истину.
Мы перестаем критически относиться к проекту, анализировать какой инструмент наиболее оптимально решит нашу задачу. Мы можем даже сами не замечать, что в какой-то момент требования в реальности так меняются, что гвозди уже давно превратились в шурупы, и вместо того, чтобы их нормально закрутить, мы продолжаем долбить молотком, только несколько сильнее, чтобы уж наверняка🙂
Когда мы сконцентрированы на нашем золотом молотке, мы постепенно перестаем смотреть по сторонам, узнавать и пробовать новые инструменты. Это уже стагнация, а в довольно динамичной ИТ отрасли стагнация примерно равна деградации.
Так работает же, что докопался?
Да, сейчас работает, но как оно будет работать завтра, через неделю, месяц или год – неизвестно. Если вы планируете еще долго расти и развиваться в ИТ, то я бы посоветовал задуматься о том, как вы работаете в последние годы и понять, не стали ли вы узником этого антипаттерна.
Что делать?
Только рефлексия и саморазвитие. Какого-то легкого и простого решения у меня для этой проблемы нет. Если у вас есть – напишите в комментариях к посту, будем знать!
Итог
Подбирайте инструменты под задачи, а не обтачивайте задачу под неподходящий инструмент. Хотя порой и это придется сделать, такова реальность нашей работы🙂
Не ведитесь на иллюзию, что вы постигли универсальную истину. Развивайтесь, пробуйте что-то новое, или хотя бы просто смотрите в сторону этого нового, узнавайте чужой опыт: кто где что как и зачем юзает.
Золотой молоток — антипаттерн проектирования, заключающийся в использовании одного и того же решения везде, в том числе путём искусственной подгонки условий, требований, ограничений задачи под данное решение. Это уверенность в полной универсальности какого-либо решения и применение этого к любым задачам.
Сталкивались ли вы с подобным, или может быть сами страдаете чем-то таким? Не торопитесь отвечать быстро, порефлексируйте. Ответ может вас удивить.
Почему мы везде видим гвозди для нашего молоточка?
На мой взгляд есть две основные причины: успешный опыт и ограниченный кругозор.
У нас за плечами уже есть какой-то успешный опыт реализации проектов. И если в этом опыте фигурирует один и тот же инструмент, технология, подход, то нам начинает казаться, что мы открыли универсальную методику и заодно абсолютную истину.
Мы перестаем критически относиться к проекту, анализировать какой инструмент наиболее оптимально решит нашу задачу. Мы можем даже сами не замечать, что в какой-то момент требования в реальности так меняются, что гвозди уже давно превратились в шурупы, и вместо того, чтобы их нормально закрутить, мы продолжаем долбить молотком, только несколько сильнее, чтобы уж наверняка🙂
Когда мы сконцентрированы на нашем золотом молотке, мы постепенно перестаем смотреть по сторонам, узнавать и пробовать новые инструменты. Это уже стагнация, а в довольно динамичной ИТ отрасли стагнация примерно равна деградации.
Так работает же, что докопался?
Да, сейчас работает, но как оно будет работать завтра, через неделю, месяц или год – неизвестно. Если вы планируете еще долго расти и развиваться в ИТ, то я бы посоветовал задуматься о том, как вы работаете в последние годы и понять, не стали ли вы узником этого антипаттерна.
Что делать?
Только рефлексия и саморазвитие. Какого-то легкого и простого решения у меня для этой проблемы нет. Если у вас есть – напишите в комментариях к посту, будем знать!
Итог
Подбирайте инструменты под задачи, а не обтачивайте задачу под неподходящий инструмент. Хотя порой и это придется сделать, такова реальность нашей работы🙂
Не ведитесь на иллюзию, что вы постигли универсальную истину. Развивайтесь, пробуйте что-то новое, или хотя бы просто смотрите в сторону этого нового, узнавайте чужой опыт: кто где что как и зачем юзает.
Хотелось бы попробовать немного разбавить в канале контент. Плюс хочется познакомить комьюнити с разными деятелями ИТ и дать возможность посмотреть на одну и ту же околорабочую проблему или ситуацию с разных точек зрения.
Изначально я планировал формат так: выбираем противоречивую / стереотипную тему, находим двух желающих встать по разные стороны баррикад, даем им слово.
Похожие форматы встречаются в подкасте у CSSSR Argumentarium, или некоторых опросах у тпрогера. Не скажу, что я хотел бы 1-в-1, или как-то у них подворовываю формат. Просто лично мне такое всегда было интересно. Можно послушать разные мнения, и вопрос поглубже понять, и новых людей к себе в копилочку добавить, как потенциально интересных.
Первую тему я выбрал - работа в аутсорсе vs работа в продукте.
Сойтись в этом микробаттле захотели:
Владимир Иванов, архитектор решений из EPAM. https://vvsevolodovich.dev/ https://twitter.com/vvsevolodovich
Вадим Мартынов, тимлид в Контуре. https://twitter.com/martynovva
От себя добавлю, что тексты хоть и не получились холиварными, как я изначально задумывал, тем не менее они поднимают интересные мысли, которые часто остаются в тени привычных нам стереотипов. В конце концов, не в холиварах счастье, а в новых идеях и новых знакомствах. Так что я очень благодарен ребятам, за то, что потратили своё время, вложили силы, поделились своими мыслями, основанными на богатом опыте.
P.S. прокомментировать, понравилась или не понравилась вам идея с дополнительным контентом, можно в комментах к этому посту. Там же можно внести свои предложения по обсуждению интересующих тем в дальнейшем. Если есть желание, можно и предложить свою кандидатуру, как потенциального обсуждателя:)
Изначально я планировал формат так: выбираем противоречивую / стереотипную тему, находим двух желающих встать по разные стороны баррикад, даем им слово.
Похожие форматы встречаются в подкасте у CSSSR Argumentarium, или некоторых опросах у тпрогера. Не скажу, что я хотел бы 1-в-1, или как-то у них подворовываю формат. Просто лично мне такое всегда было интересно. Можно послушать разные мнения, и вопрос поглубже понять, и новых людей к себе в копилочку добавить, как потенциально интересных.
Первую тему я выбрал - работа в аутсорсе vs работа в продукте.
Сойтись в этом микробаттле захотели:
Владимир Иванов, архитектор решений из EPAM. https://vvsevolodovich.dev/ https://twitter.com/vvsevolodovich
Вадим Мартынов, тимлид в Контуре. https://twitter.com/martynovva
От себя добавлю, что тексты хоть и не получились холиварными, как я изначально задумывал, тем не менее они поднимают интересные мысли, которые часто остаются в тени привычных нам стереотипов. В конце концов, не в холиварах счастье, а в новых идеях и новых знакомствах. Так что я очень благодарен ребятам, за то, что потратили своё время, вложили силы, поделились своими мыслями, основанными на богатом опыте.
P.S. прокомментировать, понравилась или не понравилась вам идея с дополнительным контентом, можно в комментах к этому посту. Там же можно внести свои предложения по обсуждению интересующих тем в дальнейшем. Если есть желание, можно и предложить свою кандидатуру, как потенциального обсуждателя:)
Мнение №1
Об аутсорсе в российском айти-секторе думают плохо: пишут мол плохой код лишь бы проект закрыть, торгуют буквально людьми, зарабатывать деньги в аутсорсе невозможно. А еще проекты все скучные, не то, что в продуктовой компании. Давайте разберёмся, насколько это все правда.
Меня зовут Владимир Иванов, я - архитектор решений в компании EPAM.
Насчёт плохого кода. Сервисные компании(мы предпочитаем называть это так) специализируются на разработке ПО. Они не продают книги или обувь, не дают площадку для услуг, не являются стриминг-сервисом. Их продукт - программное обеспечение. Если бы сервисные компании делали это плохо, с ними бы никто не работал! Более того, на деле ситуация обратная: за счёт специализации, именно сервисные компании учат продуктовые, как на самом деле работать. В этом плане приходится и объяснять как на постоянной основе тестировать безопасность и производительность, как мерять скорость работы команды, и как вообще улучшать качество кода.
Торговля людьми. Есть такой термин - бодишоп. Когда разработчика буквально продают заказчику. Такое действительно есть, и называется «аутстафф». Разработчик просто работает в команде заказчика, и все. Звучит страшно, но на деле не отличается от работы на компанию в плане технологий и интереса работы. Если вы работаете на Гугл, Убер или AirBnb, то разница будет только в том, куда вы идёте на корпоратив. Ещё конечно будет разница в деньгах, но об этом позже.
Насчёт денег. Действительно, зарплата в сервисной компании должна по идее быть меньше, чем в продуктовой, ведь продуктовая нанимает сервисную. К счастью, в сервисной компании тоже есть возможности зарабатывать деньги, но для этого надо делать что-то больше, чем просто писать код или просто тестировать. Интерес сервисной компании в том, чтобы получить больше работы у этого клиента или получить нового клиента. Таким образом, если вы этому способствуете, то можете рассчитывать на хорошие премии или на ценные бумаги. Бывает, что нужно просто пойти и спросить менеджера, что нужно сделать, чтобы получать X денег в год.
Насчёт скучных проектов: сервисные компании работают на продуктовые. Народ, наши проекты общие! Понятно, что какие-то проекты наружу не отдашь. Но таких меньшинство. Я за своё время успел поработать над сервисом знакомств, программе обучения английскому языку, над внутренним инструментом управления поставками и средству безопасному обмену файлами. И это было чертовски интересно! Кроме того, на них на всех был совершенно разный стек технологий, что даёт возможность роста вширь.
Таким образом, частая смена проекта, которая не светит вам в продукте, в сервисной компании возможна.
Вообщем, как и везде есть минусы и плюсы. Важно найти те, что перевешивают для вас.
Об аутсорсе в российском айти-секторе думают плохо: пишут мол плохой код лишь бы проект закрыть, торгуют буквально людьми, зарабатывать деньги в аутсорсе невозможно. А еще проекты все скучные, не то, что в продуктовой компании. Давайте разберёмся, насколько это все правда.
Меня зовут Владимир Иванов, я - архитектор решений в компании EPAM.
Насчёт плохого кода. Сервисные компании(мы предпочитаем называть это так) специализируются на разработке ПО. Они не продают книги или обувь, не дают площадку для услуг, не являются стриминг-сервисом. Их продукт - программное обеспечение. Если бы сервисные компании делали это плохо, с ними бы никто не работал! Более того, на деле ситуация обратная: за счёт специализации, именно сервисные компании учат продуктовые, как на самом деле работать. В этом плане приходится и объяснять как на постоянной основе тестировать безопасность и производительность, как мерять скорость работы команды, и как вообще улучшать качество кода.
Торговля людьми. Есть такой термин - бодишоп. Когда разработчика буквально продают заказчику. Такое действительно есть, и называется «аутстафф». Разработчик просто работает в команде заказчика, и все. Звучит страшно, но на деле не отличается от работы на компанию в плане технологий и интереса работы. Если вы работаете на Гугл, Убер или AirBnb, то разница будет только в том, куда вы идёте на корпоратив. Ещё конечно будет разница в деньгах, но об этом позже.
Насчёт денег. Действительно, зарплата в сервисной компании должна по идее быть меньше, чем в продуктовой, ведь продуктовая нанимает сервисную. К счастью, в сервисной компании тоже есть возможности зарабатывать деньги, но для этого надо делать что-то больше, чем просто писать код или просто тестировать. Интерес сервисной компании в том, чтобы получить больше работы у этого клиента или получить нового клиента. Таким образом, если вы этому способствуете, то можете рассчитывать на хорошие премии или на ценные бумаги. Бывает, что нужно просто пойти и спросить менеджера, что нужно сделать, чтобы получать X денег в год.
Насчёт скучных проектов: сервисные компании работают на продуктовые. Народ, наши проекты общие! Понятно, что какие-то проекты наружу не отдашь. Но таких меньшинство. Я за своё время успел поработать над сервисом знакомств, программе обучения английскому языку, над внутренним инструментом управления поставками и средству безопасному обмену файлами. И это было чертовски интересно! Кроме того, на них на всех был совершенно разный стек технологий, что даёт возможность роста вширь.
Таким образом, частая смена проекта, которая не светит вам в продукте, в сервисной компании возможна.
Вообщем, как и везде есть минусы и плюсы. Важно найти те, что перевешивают для вас.
Мнение №2
Привет, меня зовут Вадим Мартынов, я тимлид в Контуре. До этого я 5 лет программировал, архитектурил и тимлидил в аутсорсинговых компаниях разного размера, фрилансил и не только. А сегодня пообещал рассказать о том почему же продуктовые компании сила, а аутсорс — могила.
Но, конечно же, этого делать не буду. Хотя бы потому, что это (int.Infinity - 1)-ый раунд подобных разборов. А ещё, когда начинаются подобные обсуждения, то мы всё равно обсуждаем стереотипы друг о друге и развенчиваем мифы. Мифы эти не беспочвенные, но чтобы понять их истоки нужно немножко разобраться в сортах программирования.
Например, мифы про аутсорс вполне себе имеют место в мире микроаутсорса — компаний на 5-100 человек с огромным количеством мелких параллельных проектов вида "телеграм-бот для конференции нефтянников". У разработчика три одновременных проекта с переключением контекста несколько раз в день. А компании приходится утилизировать рабочее время сотрудников любой ценой, поэтому можно нечаянно пойти писать на незнакомой технологии или даже незнакомом языке. Рокет-саенс заключается в том, что на своей горящей жопе можно нечаянно улететь в космос.
Иллюстрацию стереотипов о продуктовых команиях тоже легко найти. Как?
* Поработать в ИТ-отделе не-ИТ-компании и делать внутренний продукт. Например, софт для СОУТ, которым будут пользоваться специалисты по охране труда.
* Сходить в не ИТ-компанию, которая делает не-ИТ-продукт, в котором нужна разработка. Например, самый популярный в мире гитарный синтезатор для профессиональных аудиостудий.
Или в любое другое место с похожими проблемами — бизнес оторван от разработки, разработка оторвана от бизнеса, бизнес или разработка оторваны от пользователей, бизнес или разработка оторваны от мира продуктового развития и управления продуктом. В этом случае можно получить и ощущение бесполезной работы, и те же переработки. А рокет-саенс заключается в том, что на своей горящей от легаси и "кто это вообще писал?!"-жопе можно нечаянно улететь в космос.
При этом надо понимать, что и продуктовые ИТ-гиганты и аутсорсинговые стратегические галероносцы тоже имеют свои недостатки. Но у частных ИТ-компаний такого размера независимо от их бизнес-модели есть общий бонус — они выжили и смогли дорасти и домасштабироваться до такого размера. В нагрузку к этому обычно идёт осознанное и экокологичное отношение к сотрудникам + денежная подушка, которая позволяет (и, на самом деле, заставляет) тратить деньги на развитие людей.
Разумеется, всё вышеописанное — только мой личный опыт :) Если вам плохо в ИТ-гиганте, то бегите из этого банка. Если вам хорошо в микро-аутсорсе, то обнимите фаундера, он, видимо, хороший человек. Или, возможно, он просто очень хорошо умеет подбирать людей и строить семейную атмосферу в компании, которая уничтожает волю.
Ужасные новости напоследок — посты в телеграме и на хабре врут и/или являются рекламой. Чтобы выбрать по-настоящему придётся сходить и попробовать всё самому. И вот вам напоследок вопрос: как много вы встречали людей, которые бы сбегали в аутсорсинговую компанию с комментарием "АААА неет, продуктовая разработка — больше никогда в жизни"?
Привет, меня зовут Вадим Мартынов, я тимлид в Контуре. До этого я 5 лет программировал, архитектурил и тимлидил в аутсорсинговых компаниях разного размера, фрилансил и не только. А сегодня пообещал рассказать о том почему же продуктовые компании сила, а аутсорс — могила.
Но, конечно же, этого делать не буду. Хотя бы потому, что это (int.Infinity - 1)-ый раунд подобных разборов. А ещё, когда начинаются подобные обсуждения, то мы всё равно обсуждаем стереотипы друг о друге и развенчиваем мифы. Мифы эти не беспочвенные, но чтобы понять их истоки нужно немножко разобраться в сортах программирования.
Например, мифы про аутсорс вполне себе имеют место в мире микроаутсорса — компаний на 5-100 человек с огромным количеством мелких параллельных проектов вида "телеграм-бот для конференции нефтянников". У разработчика три одновременных проекта с переключением контекста несколько раз в день. А компании приходится утилизировать рабочее время сотрудников любой ценой, поэтому можно нечаянно пойти писать на незнакомой технологии или даже незнакомом языке. Рокет-саенс заключается в том, что на своей горящей жопе можно нечаянно улететь в космос.
Иллюстрацию стереотипов о продуктовых команиях тоже легко найти. Как?
* Поработать в ИТ-отделе не-ИТ-компании и делать внутренний продукт. Например, софт для СОУТ, которым будут пользоваться специалисты по охране труда.
* Сходить в не ИТ-компанию, которая делает не-ИТ-продукт, в котором нужна разработка. Например, самый популярный в мире гитарный синтезатор для профессиональных аудиостудий.
Или в любое другое место с похожими проблемами — бизнес оторван от разработки, разработка оторвана от бизнеса, бизнес или разработка оторваны от пользователей, бизнес или разработка оторваны от мира продуктового развития и управления продуктом. В этом случае можно получить и ощущение бесполезной работы, и те же переработки. А рокет-саенс заключается в том, что на своей горящей от легаси и "кто это вообще писал?!"-жопе можно нечаянно улететь в космос.
При этом надо понимать, что и продуктовые ИТ-гиганты и аутсорсинговые стратегические галероносцы тоже имеют свои недостатки. Но у частных ИТ-компаний такого размера независимо от их бизнес-модели есть общий бонус — они выжили и смогли дорасти и домасштабироваться до такого размера. В нагрузку к этому обычно идёт осознанное и экокологичное отношение к сотрудникам + денежная подушка, которая позволяет (и, на самом деле, заставляет) тратить деньги на развитие людей.
Разумеется, всё вышеописанное — только мой личный опыт :) Если вам плохо в ИТ-гиганте, то бегите из этого банка. Если вам хорошо в микро-аутсорсе, то обнимите фаундера, он, видимо, хороший человек. Или, возможно, он просто очень хорошо умеет подбирать людей и строить семейную атмосферу в компании, которая уничтожает волю.
Ужасные новости напоследок — посты в телеграме и на хабре врут и/или являются рекламой. Чтобы выбрать по-настоящему придётся сходить и попробовать всё самому. И вот вам напоследок вопрос: как много вы встречали людей, которые бы сбегали в аутсорсинговую компанию с комментарием "АААА неет, продуктовая разработка — больше никогда в жизни"?
Привет!
С вами Тимлид Очевидность (Евгений Антонов).
Хочу поблагодарить вас за то, что читаете, а иногда ещё комментируете и дискутируете❤️
Надеюсь, мой канал был вам полезен и как источник знаний, и как место для общения.
Канал я создал в самом начале года, просто как способ выговориться и осветить темы, которые я вижу проблемными в реальной жизни.
Честно говоря, не ожидал, что он наберёт столько подписчиков. Ровно как и от консалтинга не ожидал, что уже в этом году удастся помочь стольким людям.
Внимание! Первый раз за год не будет очередного пятничного поста.
Я его уже подготовил, но решил никого не грузить 1-го января 🙂
Отдохните хорошенечко, отвлекитесь от выжигания глазок монитором, посмотрите на жизнь вне работы, проведите время с семьёй, погуляйте, почитайте, поиграйте, посмотрите всякое. Займитесь тем, что давно откладывали в угоду работе.
Если хорошо отдохнуть, то на работу можно выйти после каникул с желанием и силами свернуть горы 👍
А очередной пятничный пост вас будет ждать 8 января.
С наступающим вас новым годом. Всем желаю, чтобы 2021 был лучше, ярче, продуктивнее и безопаснее, чем 2020 🌲💪
С вами Тимлид Очевидность (Евгений Антонов).
Хочу поблагодарить вас за то, что читаете, а иногда ещё комментируете и дискутируете❤️
Надеюсь, мой канал был вам полезен и как источник знаний, и как место для общения.
Канал я создал в самом начале года, просто как способ выговориться и осветить темы, которые я вижу проблемными в реальной жизни.
Честно говоря, не ожидал, что он наберёт столько подписчиков. Ровно как и от консалтинга не ожидал, что уже в этом году удастся помочь стольким людям.
Внимание! Первый раз за год не будет очередного пятничного поста.
Я его уже подготовил, но решил никого не грузить 1-го января 🙂
Отдохните хорошенечко, отвлекитесь от выжигания глазок монитором, посмотрите на жизнь вне работы, проведите время с семьёй, погуляйте, почитайте, поиграйте, посмотрите всякое. Займитесь тем, что давно откладывали в угоду работе.
Если хорошо отдохнуть, то на работу можно выйти после каникул с желанием и силами свернуть горы 👍
А очередной пятничный пост вас будет ждать 8 января.
С наступающим вас новым годом. Всем желаю, чтобы 2021 был лучше, ярче, продуктивнее и безопаснее, чем 2020 🌲💪
Умей отказывать
Умение сказать «нет» - один из лучших и полезнейших навыков, который вам понадобится в любом аспекте жизни. Но так как мой канал больше про работу, то хотелось бы рассмотреть данный скилл именно в этом ключе.
Надо сделать позавчера. Заранее спасибо!
Я (да и вы, я уверен, тоже) очень часто вижу множественные примеры манипулятивного поведения и морального давления. В итоге, кто под давлением прогнулся, тот все проблемы на себе и вывозит.
Например, это выглядит как-то так:
«Нам надо тут так срочно, что аж вчера! ПРЯМО АСАП!! Сделаешь, дорогой/котик/рыбка/птичка/зайчик, да? Заранее спасибо!».
Зачастую, если перевести на человеческий язык, то получится что-то типа «Мы тут продолбались, тебя подставили, щас начнем тебя гнуть, и если ты прогнешься, то ты и втухнешь в этом деле. И к тому же, если вдруг что-то пойдет не так, ты еще и виноватым будешь».
И вот на такое, якобы дружелюбное, предложение взвалить на себя весь чужой гемор, многим людям трудно отказать. Даже если это не их работа, даже если они сейчас заняты, даже если у них еще куча других пожаров. Они соглашаются, потому что «ну неудобно же», «а что обо мне подумают», а потом:
- Морально страдают от того, что ничего не успевают.
- Физически страдают от того, что раз не успевают, то надо сверхурочно поработать.
- Еще раз морально страдают, потому что какие-то свои проблемы не решили и, возможно, других людей подвели.
Нет/не могу/не сейчас
А ведь можно было бы избежать этих страданий. Достаточно было бы в той или иной форме отказать (если это уместно).
Фразу «ну неудобно же отказывать» желательно совсем выкинуть из своей головы. Вы профессионалы, эффективно делаете свою работу за деньги. И вот если вам начинают подсовывать свои проблемы, которые мешают выполнять вашу работу, то разумнее всего или отказать, или отложить на более удобное время.
Если кто-то со своими проблемами не справляется и стремится их переметнуть на вас, то это и проявление непрофессионализма, и препятствие для вашей работы, а в некоторых случаях даже и неуважение к вам, вашему времени, вашему труду. А если вам человек мешает, или не уважает ваш труд, то почему вас должно беспокоить «что он обо мне подумает, если я откажу»? Подумает он о вас ровно одно «с этим не прокатило, пойду поищу другого дурачка, чтобы на него подсесть». Зачастую такие мутные просьбы идут от людей, которым конкретно вы даже ничего не должны.
Всё, что вам нужно сделать - это в момент психологического давления успокоиться, не торопиться соглашаться и хорошенько обдумать ситуацию. Если она вам кажется неудобной, то так об этом и сказать. Это вас о чем-то просят, это от вас что-то нужно. Так что либо о вашем комфорте позаботятся и найдут какой-то компромисс, либо вы останетесь при своем.
Но мы же друзья, мы же команда
Справедливо отметить, что иногда просьбы, которые вам вроде бы делать необязательно, на которые можно отказать, можно в итоге сделать ради поддержания хороших отношений, темпа командной работы и т. д.
Да, если всегда как робот действовать только по должностной инструкции и никому не идти навстречу, то можно и команду подвести, и мудаком в целом прослыть.
Однако, если мы говорим о просьбах, где вы можете пойти навстречу, помочь товарищу, сделать проекту лучше, то это будут несколько другие просьбы. Чем они другие?
При этом у вас уточнят:
- Удобно ли вам это будет сделать? (Вместо «Сделай!»)
- Когда вы это сможете сделать, если сможете? (Вместо «НАДО АСАП ПОЗАВЧЕРА!»)
- Дадут вам право на отказ (вместо «давай, уже вечер, а мне завтра утром заказчику показывать!»)
А ты сам что?
Я сам стараюсь работать так, чтобы свою работу точно сделать хорошо, и по возможности еще помочь коллегам. Помочь, а не сделать всю работу за того, кто не стал разбираться. Стараюсь идти навстречу, и сам прошу помощи так, чтобы и другим людям было не обременительно пойти навстречу мне.
Умение сказать «нет» - один из лучших и полезнейших навыков, который вам понадобится в любом аспекте жизни. Но так как мой канал больше про работу, то хотелось бы рассмотреть данный скилл именно в этом ключе.
Надо сделать позавчера. Заранее спасибо!
Я (да и вы, я уверен, тоже) очень часто вижу множественные примеры манипулятивного поведения и морального давления. В итоге, кто под давлением прогнулся, тот все проблемы на себе и вывозит.
Например, это выглядит как-то так:
«Нам надо тут так срочно, что аж вчера! ПРЯМО АСАП!! Сделаешь, дорогой/котик/рыбка/птичка/зайчик, да? Заранее спасибо!».
Зачастую, если перевести на человеческий язык, то получится что-то типа «Мы тут продолбались, тебя подставили, щас начнем тебя гнуть, и если ты прогнешься, то ты и втухнешь в этом деле. И к тому же, если вдруг что-то пойдет не так, ты еще и виноватым будешь».
И вот на такое, якобы дружелюбное, предложение взвалить на себя весь чужой гемор, многим людям трудно отказать. Даже если это не их работа, даже если они сейчас заняты, даже если у них еще куча других пожаров. Они соглашаются, потому что «ну неудобно же», «а что обо мне подумают», а потом:
- Морально страдают от того, что ничего не успевают.
- Физически страдают от того, что раз не успевают, то надо сверхурочно поработать.
- Еще раз морально страдают, потому что какие-то свои проблемы не решили и, возможно, других людей подвели.
Нет/не могу/не сейчас
А ведь можно было бы избежать этих страданий. Достаточно было бы в той или иной форме отказать (если это уместно).
Фразу «ну неудобно же отказывать» желательно совсем выкинуть из своей головы. Вы профессионалы, эффективно делаете свою работу за деньги. И вот если вам начинают подсовывать свои проблемы, которые мешают выполнять вашу работу, то разумнее всего или отказать, или отложить на более удобное время.
Если кто-то со своими проблемами не справляется и стремится их переметнуть на вас, то это и проявление непрофессионализма, и препятствие для вашей работы, а в некоторых случаях даже и неуважение к вам, вашему времени, вашему труду. А если вам человек мешает, или не уважает ваш труд, то почему вас должно беспокоить «что он обо мне подумает, если я откажу»? Подумает он о вас ровно одно «с этим не прокатило, пойду поищу другого дурачка, чтобы на него подсесть». Зачастую такие мутные просьбы идут от людей, которым конкретно вы даже ничего не должны.
Всё, что вам нужно сделать - это в момент психологического давления успокоиться, не торопиться соглашаться и хорошенько обдумать ситуацию. Если она вам кажется неудобной, то так об этом и сказать. Это вас о чем-то просят, это от вас что-то нужно. Так что либо о вашем комфорте позаботятся и найдут какой-то компромисс, либо вы останетесь при своем.
Но мы же друзья, мы же команда
Справедливо отметить, что иногда просьбы, которые вам вроде бы делать необязательно, на которые можно отказать, можно в итоге сделать ради поддержания хороших отношений, темпа командной работы и т. д.
Да, если всегда как робот действовать только по должностной инструкции и никому не идти навстречу, то можно и команду подвести, и мудаком в целом прослыть.
Однако, если мы говорим о просьбах, где вы можете пойти навстречу, помочь товарищу, сделать проекту лучше, то это будут несколько другие просьбы. Чем они другие?
При этом у вас уточнят:
- Удобно ли вам это будет сделать? (Вместо «Сделай!»)
- Когда вы это сможете сделать, если сможете? (Вместо «НАДО АСАП ПОЗАВЧЕРА!»)
- Дадут вам право на отказ (вместо «давай, уже вечер, а мне завтра утром заказчику показывать!»)
А ты сам что?
Я сам стараюсь работать так, чтобы свою работу точно сделать хорошо, и по возможности еще помочь коллегам. Помочь, а не сделать всю работу за того, кто не стал разбираться. Стараюсь идти навстречу, и сам прошу помощи так, чтобы и другим людям было не обременительно пойти навстречу мне.
Однако есть категории граждан, которым приходится в явном виде отказывать. Когда я чувствую, что на меня садятся, закидывают свои проблемы, свою работу и начинают пришпоривать, чтобы я всё это вывозил, то я тут же их сбрасываю. В идеале даже не дать им успеть наверх залезть. Таких если сразу не высадить, то чем дальше ты их везешь, тем тяжелее будет это сделать.
Лично в моей практике частота, с которой приходится говорить «нет», увеличивалась по мере трансформации из рядового разработчика в тимлида. Тут и обычному разрабу сверху задач накидывают много левых, а тимлиду еще и сбоку, и снизу прилетает.
Всем не поможешь, даже если вдруг все запросы на помощь вполне валидные. Приходится иногда отказывать, не потому что человек свои проблемы на тебя валит, а просто потому что уже не можешь всё успеть и надо приоритизировать.
Итог
Думайте о своем комфорте, о своей работе в первую очередь. О товарищах тоже заботьтесь, но не в ущерб себе. Кроме вас самих, мало кто другой о вас позаботится.
Не стесняйтесь, не бойтесь, не переживайте, отказывать - это нормально.
Смело отказывайте сами и давайте право на отказ другим.
Лично в моей практике частота, с которой приходится говорить «нет», увеличивалась по мере трансформации из рядового разработчика в тимлида. Тут и обычному разрабу сверху задач накидывают много левых, а тимлиду еще и сбоку, и снизу прилетает.
Всем не поможешь, даже если вдруг все запросы на помощь вполне валидные. Приходится иногда отказывать, не потому что человек свои проблемы на тебя валит, а просто потому что уже не можешь всё успеть и надо приоритизировать.
Итог
Думайте о своем комфорте, о своей работе в первую очередь. О товарищах тоже заботьтесь, но не в ущерб себе. Кроме вас самих, мало кто другой о вас позаботится.
Не стесняйтесь, не бойтесь, не переживайте, отказывать - это нормально.
Смело отказывайте сами и давайте право на отказ другим.
Зачем заводить задачу, если дел на 5 минут?
Часто сталкиваюсь с мнением, что задачу заводить не надо (ибо впадлу), если саму задачу делать 5 минут, а заводить её сравнимые минуты 2-3.
Также порой сталкиваюсь с последствиями такого решения.
Надо заводить
Для себя я вывел правило, что если работы по этой задаче кого-то будут аффектить, то надо заводить задачу. Кого-то - это кого? Любого, кроме меня, или меня в будущем.
Например, надо пофиксить какую-то штучку за 5 минут. Я (или кто-то) написал код за 5 минут и запушил коммит без привязки к задаче, в которой могла быть раскрыта история фикса и почему надо было делать именно то, что сделали.
Сделали быстро, оно работает и без задачи. Правда потом, когда спустя N времени что-то еще надо в том районе поправить – никто и не догадается почему оно сделано именно так, а не иначе. Никакой истории запросов заказчика, обсуждения проблемы, приемки фикса – ничего этого нет.
В результате непонятно зачем сделали именно так, и поди докажи, что заказчик хотел именно этого и в тот самый фикс он принял работу и остался доволен.
Или представим, что есть какой-нибудь документ, содержащий спецификацию. В какой-то момент его отредактировали за 3 минуты, а задачи не было. Ну и всё, заводи хрустальный шар, выходи в астрал и разбирайся кто, что, зачем, когда и почему менял.
А на галерах, где работу программистов продают по часам, так и вообще такой дилеммы нет в принципе. Всё должно быть задокументировано, затрекано, принято заказчиком и оплачено.
Не надо заводить
Есть такие случаи, где и правда заводить задачу – трата времени и, будем честны, еще и нервов. Действительно порой так неохота идти в трекер, создавать задачу, писать описание, назначать людей, выставлять всякие разные атрибуты и т. д.
Например, у меня - это написание ежемесячного отчета. Есть напоминалка, которая раз в месяц стреляет. Я точно знаю, что я её не пропущу, точно уверен, что отчет написать не забуду, точно уверен, что, написав его, отправлю куда надо. Мне не надо для этого каждый месяц еще себе задачу одинаковую создавать.
В ней не будет никакой полезной информации. Там нет никакой истории развития, нет никаких изменений, нет никакого контента, который бы пригодился мне или моим коллегам в настоящем или будущем.
Итог
Пока писал этот пост, заметил, что придумать примеры для того, что надо заводить задачу, мне было намного легче, чем для того, когда не надо.
Моё мнение: задачи могут быть полезны, даже когда ты работаешь один (чтобы хранить историю), а уж когда ты работаешь в команде, то прям совсем незаменимы.
Боритесь с ленью (или делегируйте), заводите задачи. В будущем вам спасибо скажут ваши коллеги, или вы сами себе🙂
Часто сталкиваюсь с мнением, что задачу заводить не надо (ибо впадлу), если саму задачу делать 5 минут, а заводить её сравнимые минуты 2-3.
Также порой сталкиваюсь с последствиями такого решения.
Надо заводить
Для себя я вывел правило, что если работы по этой задаче кого-то будут аффектить, то надо заводить задачу. Кого-то - это кого? Любого, кроме меня, или меня в будущем.
Например, надо пофиксить какую-то штучку за 5 минут. Я (или кто-то) написал код за 5 минут и запушил коммит без привязки к задаче, в которой могла быть раскрыта история фикса и почему надо было делать именно то, что сделали.
Сделали быстро, оно работает и без задачи. Правда потом, когда спустя N времени что-то еще надо в том районе поправить – никто и не догадается почему оно сделано именно так, а не иначе. Никакой истории запросов заказчика, обсуждения проблемы, приемки фикса – ничего этого нет.
В результате непонятно зачем сделали именно так, и поди докажи, что заказчик хотел именно этого и в тот самый фикс он принял работу и остался доволен.
Или представим, что есть какой-нибудь документ, содержащий спецификацию. В какой-то момент его отредактировали за 3 минуты, а задачи не было. Ну и всё, заводи хрустальный шар, выходи в астрал и разбирайся кто, что, зачем, когда и почему менял.
А на галерах, где работу программистов продают по часам, так и вообще такой дилеммы нет в принципе. Всё должно быть задокументировано, затрекано, принято заказчиком и оплачено.
Не надо заводить
Есть такие случаи, где и правда заводить задачу – трата времени и, будем честны, еще и нервов. Действительно порой так неохота идти в трекер, создавать задачу, писать описание, назначать людей, выставлять всякие разные атрибуты и т. д.
Например, у меня - это написание ежемесячного отчета. Есть напоминалка, которая раз в месяц стреляет. Я точно знаю, что я её не пропущу, точно уверен, что отчет написать не забуду, точно уверен, что, написав его, отправлю куда надо. Мне не надо для этого каждый месяц еще себе задачу одинаковую создавать.
В ней не будет никакой полезной информации. Там нет никакой истории развития, нет никаких изменений, нет никакого контента, который бы пригодился мне или моим коллегам в настоящем или будущем.
Итог
Пока писал этот пост, заметил, что придумать примеры для того, что надо заводить задачу, мне было намного легче, чем для того, когда не надо.
Моё мнение: задачи могут быть полезны, даже когда ты работаешь один (чтобы хранить историю), а уж когда ты работаешь в команде, то прям совсем незаменимы.
Боритесь с ленью (или делегируйте), заводите задачи. В будущем вам спасибо скажут ваши коллеги, или вы сами себе🙂
Продолжаю серию постов от приглашенных гостей.
Сегодня Антон и Никита из подкаста "Цинковый прод" (https://znprod.io/) порассуждают на тему "нужно ли при изучении нового инструмента закапываться сначала в теорию или как можно раньше приступать к практике?"
Если вы еще не слушаете Цинковый прод, то приходите послушать тут https://soundcloud.com/znprod, или посмотреть здесь https://www.youtube.com/channel/UC6cTShKx3lJWw-EzSr_ZAfw
Практик Никита
Женя решил немного взбодрить нас и ввязал в дискуссию по поводу изучения нового инструментария для программистов.
Я выступаю в роли защитника попсовой точки зрения "делай - читай 80/20".
Для начала хотел бы предложить читателю выяснить для чего вообще вам нужен новый инструмент? Какие могут быть варианты:
- Продали руководству идею добавления этого инструмента в стек компании;
- Решили сменить работу и вам необходим дополнительный навык;
- Покрасоваться новым инструментом в вашем репозитории на GitHub;
- В чате по другой технологии тусуется человек, который вам нравится и вы хотите влиться, чтобы поближе познакомиться;
- Хотите больше денег, потому что у вас размер ЗП зависит от стека знаний;
- Добавьте свой вариант.
Мне в голову приходит недавний разговор с коллегой, который назвал изучение и поиск новых инструментов одним из видов прокрастинации.
Уточню, что он имел в виду. Представьте себе ситуацию: все вокруг обсуждают монады и решив, что они вам нужны, вы хотите нырнуть в изучение haskell, т.к. только там можно познать дзен этой абстракции. Но если ваша цель стать руководителем разработки, то изучение Haskell - не лучшая инвестиция времени.
Итак вы определились со своей глобальной целью и точно понимаете, что вам нужно добавить конкретный инструмент в свой стек. Я приверженец MVP подхода, т.е. необходимо в макисимально сжатые сроки набрать минимально необходимые для применения на практике знания. Затем сразу же приступить к их применению/продаже.
Например в ближайших планах у вас - стать админом облачной инфраструктуры, а вы не знаете как рабоатать с kubernetes.
В таком случае изучение k8s полностью совпадает с вашей целью, и для уменьшения времени получения результата я бы порекомендовал бросаться сразу в бой. Несомненно вам придется для начала прочитать тройку уроков и, возможно, посмотреть пару видео. Затем ищите уже реализованный проект на GitHub (или пошаговый tutorial) и копируйте его. По шагам понимаете, что и как нужно изменить, чтобы получить результат.
Если вы еще не пробовали такой подход, то рекомендую попробовать уменьшить количество чтения и пораньше “спрыгивать” на практику.
Плюсы:
- Быстро дает практический навык и опыт решения возникающих проблем;
- Приучает тратить минимум энергии/времени/маны на проверку теорий или сравнительное тестирование;
- Применение возможно в ситуациях требующих быстрого входа, а это большая часть проблем;
- Популярный способ входа, поэтому велика вероятность, что вы быстро найедете решение ошибок, возникающих у большинства.
Минусы:
- Поверхностное погружение в технологию на первых шагах;
- Опасность эффекта Даннинга-Крюгера (когда мало знаешь об инструменте, но думаешь, что познал дзен).
Сегодня Антон и Никита из подкаста "Цинковый прод" (https://znprod.io/) порассуждают на тему "нужно ли при изучении нового инструмента закапываться сначала в теорию или как можно раньше приступать к практике?"
Если вы еще не слушаете Цинковый прод, то приходите послушать тут https://soundcloud.com/znprod, или посмотреть здесь https://www.youtube.com/channel/UC6cTShKx3lJWw-EzSr_ZAfw
Практик Никита
Женя решил немного взбодрить нас и ввязал в дискуссию по поводу изучения нового инструментария для программистов.
Я выступаю в роли защитника попсовой точки зрения "делай - читай 80/20".
Для начала хотел бы предложить читателю выяснить для чего вообще вам нужен новый инструмент? Какие могут быть варианты:
- Продали руководству идею добавления этого инструмента в стек компании;
- Решили сменить работу и вам необходим дополнительный навык;
- Покрасоваться новым инструментом в вашем репозитории на GitHub;
- В чате по другой технологии тусуется человек, который вам нравится и вы хотите влиться, чтобы поближе познакомиться;
- Хотите больше денег, потому что у вас размер ЗП зависит от стека знаний;
- Добавьте свой вариант.
Мне в голову приходит недавний разговор с коллегой, который назвал изучение и поиск новых инструментов одним из видов прокрастинации.
Уточню, что он имел в виду. Представьте себе ситуацию: все вокруг обсуждают монады и решив, что они вам нужны, вы хотите нырнуть в изучение haskell, т.к. только там можно познать дзен этой абстракции. Но если ваша цель стать руководителем разработки, то изучение Haskell - не лучшая инвестиция времени.
Итак вы определились со своей глобальной целью и точно понимаете, что вам нужно добавить конкретный инструмент в свой стек. Я приверженец MVP подхода, т.е. необходимо в макисимально сжатые сроки набрать минимально необходимые для применения на практике знания. Затем сразу же приступить к их применению/продаже.
Например в ближайших планах у вас - стать админом облачной инфраструктуры, а вы не знаете как рабоатать с kubernetes.
В таком случае изучение k8s полностью совпадает с вашей целью, и для уменьшения времени получения результата я бы порекомендовал бросаться сразу в бой. Несомненно вам придется для начала прочитать тройку уроков и, возможно, посмотреть пару видео. Затем ищите уже реализованный проект на GitHub (или пошаговый tutorial) и копируйте его. По шагам понимаете, что и как нужно изменить, чтобы получить результат.
Если вы еще не пробовали такой подход, то рекомендую попробовать уменьшить количество чтения и пораньше “спрыгивать” на практику.
Плюсы:
- Быстро дает практический навык и опыт решения возникающих проблем;
- Приучает тратить минимум энергии/времени/маны на проверку теорий или сравнительное тестирование;
- Применение возможно в ситуациях требующих быстрого входа, а это большая часть проблем;
- Популярный способ входа, поэтому велика вероятность, что вы быстро найедете решение ошибок, возникающих у большинства.
Минусы:
- Поверхностное погружение в технологию на первых шагах;
- Опасность эффекта Даннинга-Крюгера (когда мало знаешь об инструменте, но думаешь, что познал дзен).
Теоретик Антон
В этом посте я буду защищать позицию теоретика, а именно: инструкцию читать всё же иногда надо.
Наверное, каждый программист проходил через этот цикл: скопировал кусок кода со stackoverflow или "hello, world"-туториала, чуть допилил напильником - и заработало. “Ура, я знаю новую технологию!” Это окрыляет, и кажется, что теперь можно всё изучать сразу на практике.
Однако это работает мягко говоря не всегда. Прямо скажем, это ОК только для простых и средне-простых задач. Возьмём, к примеру, Rust, и его заморочки с памятью. При разработке вы сразу столкнетесь с выбором. Что использовать: &T или &mut T? А может, Cell<T>? Box<T>? Rc<Refcell<T>> ? А чем Mutex<T> отличается от Arc<Mutex<T>>? Тысячи их, таких вопросов.
Т.е. на практике это будет выглядеть так: вы пробуете что-то написать, компилятор Rust говорит “ты дебил”. Пробуете другое - компилятор говорит, что всё равно дебил, попробуй еще раз. Stackoverflow поможет очень слабо. Нужно читать Rust Book, без вариантов.
Еще пример. Вы захотели написать свой язык программирования. Где-то слышали, что надо сначала сделать парсер, который преобразует текст в AST-дерево. Попробуйте это сделать интуитивно, без теории. Это совсем непросто. Как описать грамматику? Что такое сканнер (токенайзер)? Как сделать сканнер быстрым? Там огромное количество вопросов, которые придется переизобретать. Гораздо быстрее будет прочесть книжку, например от создателя Dart: https://craftinginterpreters.com/contents.html
Вообще, в сложных задачах есть всего два пути, изобретать самому или пользоваться изобретениями других людей. Изобретать самому интереснее, но в 100 раз дольше.
Иногда нужно знать теорию в смежных областях, не только в самой IT. Взять, например, математическую статистику. Сколько нужно экспериментов, чтобы достоверно сказать, что такой способ размещения рекламы на сайте наиболее выгоден?
Некоторые вещи не столь конкретны, но не менее важны. Например, куча говнокода возникает только из-за того, что человек не удосужился прочесть ни одной книги про качество кода. Ты с ним говоришь как будто на разных языках. Даже очевидные вещи, например, god object или слишком большой и запутанный метод, могут вызывать споры на тему “а надо ли это упрощать”.
В общем, рано, рано еще теорию списывать со счетов. Без теории запросто можно красить кнопки, но вот создать что-то по настоящему сложное или ответственное - увы.
В этом посте я буду защищать позицию теоретика, а именно: инструкцию читать всё же иногда надо.
Наверное, каждый программист проходил через этот цикл: скопировал кусок кода со stackoverflow или "hello, world"-туториала, чуть допилил напильником - и заработало. “Ура, я знаю новую технологию!” Это окрыляет, и кажется, что теперь можно всё изучать сразу на практике.
Однако это работает мягко говоря не всегда. Прямо скажем, это ОК только для простых и средне-простых задач. Возьмём, к примеру, Rust, и его заморочки с памятью. При разработке вы сразу столкнетесь с выбором. Что использовать: &T или &mut T? А может, Cell<T>? Box<T>? Rc<Refcell<T>> ? А чем Mutex<T> отличается от Arc<Mutex<T>>? Тысячи их, таких вопросов.
Т.е. на практике это будет выглядеть так: вы пробуете что-то написать, компилятор Rust говорит “ты дебил”. Пробуете другое - компилятор говорит, что всё равно дебил, попробуй еще раз. Stackoverflow поможет очень слабо. Нужно читать Rust Book, без вариантов.
Еще пример. Вы захотели написать свой язык программирования. Где-то слышали, что надо сначала сделать парсер, который преобразует текст в AST-дерево. Попробуйте это сделать интуитивно, без теории. Это совсем непросто. Как описать грамматику? Что такое сканнер (токенайзер)? Как сделать сканнер быстрым? Там огромное количество вопросов, которые придется переизобретать. Гораздо быстрее будет прочесть книжку, например от создателя Dart: https://craftinginterpreters.com/contents.html
Вообще, в сложных задачах есть всего два пути, изобретать самому или пользоваться изобретениями других людей. Изобретать самому интереснее, но в 100 раз дольше.
Иногда нужно знать теорию в смежных областях, не только в самой IT. Взять, например, математическую статистику. Сколько нужно экспериментов, чтобы достоверно сказать, что такой способ размещения рекламы на сайте наиболее выгоден?
Некоторые вещи не столь конкретны, но не менее важны. Например, куча говнокода возникает только из-за того, что человек не удосужился прочесть ни одной книги про качество кода. Ты с ним говоришь как будто на разных языках. Даже очевидные вещи, например, god object или слишком большой и запутанный метод, могут вызывать споры на тему “а надо ли это упрощать”.
В общем, рано, рано еще теорию списывать со счетов. Без теории запросто можно красить кнопки, но вот создать что-то по настоящему сложное или ответственное - увы.
Ошибка выжившего в ИТ
Что это такое?
Википедия говорит, что систематическая ошибка выжившего — разновидность систематической ошибки отбора, когда по одной группе объектов данных много, а по другой — практически нет. В результате исследователи пытаются искать общие черты среди «выживших» и упускают из вида, что не менее важная информация скрывается среди «погибших».
Где это в ИТ?
Да почти везде. Почти любой хайп вокруг технологии и рабочих процессов пляшет на ошибке выжившего. А множественные конференции и доклады задают ритм.
Ведь конференции - это в большинстве своем истории успеха:
- Мы перешли на микросервисы и волосы стали шелковистые;
- Мы внедрили скрам и стали работать в 7.5 тысяч раз лучше;
- Мы переписали всё на реакт и теперь сайт открывается быстрее, чем вы успели об этом подумать.
Всё это искажает у слушателя объективное представление о плюсах и минусах, заставляя его верить, что если у кого-то получилось (у кого-то в другой команде, компании, стране, проекте, и т. д.), то и у него 146% получится.
Что делать?
Я не спорю с тем, что истории успеха важны, нужны и бывают полезны.
Просто хочется, чтобы почаще рассказывали на конференциях еще и истории неудач, как микросервисы завалили проект (кстати про микросервисы один хороший доклад, рассматривающий обильно негативные стороны, я видел), как скрам накрутил бюрократизации и истрепал нервы команде, как говнокод, на что бы ни был переписан, всё равно остается говнокодом.
А еще неплохо было бы нам всем постараться критически мыслить, стараясь продумать, разглядеть и спрогнозировать возможные подводные камни, а не просто слепо доверять какому-то докладчику и кидаться повторять всё 1 в 1.
Пример
Знаю компанию, где выписали себе за дорого аджайл коуча / скрам мастера, который на волне хайпа и успешных историй про скрам пришел, срубил кучу денег, переформатировал команды, процессы, навел шороху и… в результате стало как минимум не лучше. Time to market не увеличился, пропускная способность разработки не выросла, touch time не вырос. Только еще и команда теперь недовольна.
Итог
Как всегда, я выступаю за критическое мышление и анализ вашей конкретной ситуации, а не просто бездумное повторение за кем-то.
Ну и, если у вас есть истории фейлов – не бойтесь ими делиться. Возможно, вы кому-то этим сильно поможете.
Что это такое?
Википедия говорит, что систематическая ошибка выжившего — разновидность систематической ошибки отбора, когда по одной группе объектов данных много, а по другой — практически нет. В результате исследователи пытаются искать общие черты среди «выживших» и упускают из вида, что не менее важная информация скрывается среди «погибших».
Где это в ИТ?
Да почти везде. Почти любой хайп вокруг технологии и рабочих процессов пляшет на ошибке выжившего. А множественные конференции и доклады задают ритм.
Ведь конференции - это в большинстве своем истории успеха:
- Мы перешли на микросервисы и волосы стали шелковистые;
- Мы внедрили скрам и стали работать в 7.5 тысяч раз лучше;
- Мы переписали всё на реакт и теперь сайт открывается быстрее, чем вы успели об этом подумать.
Всё это искажает у слушателя объективное представление о плюсах и минусах, заставляя его верить, что если у кого-то получилось (у кого-то в другой команде, компании, стране, проекте, и т. д.), то и у него 146% получится.
Что делать?
Я не спорю с тем, что истории успеха важны, нужны и бывают полезны.
Просто хочется, чтобы почаще рассказывали на конференциях еще и истории неудач, как микросервисы завалили проект (кстати про микросервисы один хороший доклад, рассматривающий обильно негативные стороны, я видел), как скрам накрутил бюрократизации и истрепал нервы команде, как говнокод, на что бы ни был переписан, всё равно остается говнокодом.
А еще неплохо было бы нам всем постараться критически мыслить, стараясь продумать, разглядеть и спрогнозировать возможные подводные камни, а не просто слепо доверять какому-то докладчику и кидаться повторять всё 1 в 1.
Пример
Знаю компанию, где выписали себе за дорого аджайл коуча / скрам мастера, который на волне хайпа и успешных историй про скрам пришел, срубил кучу денег, переформатировал команды, процессы, навел шороху и… в результате стало как минимум не лучше. Time to market не увеличился, пропускная способность разработки не выросла, touch time не вырос. Только еще и команда теперь недовольна.
Итог
Как всегда, я выступаю за критическое мышление и анализ вашей конкретной ситуации, а не просто бездумное повторение за кем-то.
Ну и, если у вас есть истории фейлов – не бойтесь ими делиться. Возможно, вы кому-то этим сильно поможете.
О моем консалтинге
Чуть меньше года назад я анонсировал свои услуги по консалтингу https://antonov-dev.ru/consulting и сегодня хотел бы немного рассказать о том, что из этого получается.
Почему я это начал?
Помогать людям разрешать их проблемы, если у меня есть для этого необходимые знания, мне всегда нравилось. Постоянно в тех или иных комьюнити я старался отвечать людям на вопросы, давать какие-то советы, помогать по мере возможностей.
Например, еще задолго до консалтинга я в этих своих альтруистических порывах помог со сменой работы на более интересную/высокооплачиваемую примерно десятку человек.
Где-то помогал рекомендациями (если искренне мог порекомендовать человека), где-то советами куда пойти, как торговаться, сколько просить и т. д.
По мере своего профессионального развития, приобретения житейского опыта и прыгания по граблям эта потребность и возможность помогать вышла на более, так скажем, качественный уровень.
Однако появилась и проблема.
Часто, желая лучшего, вкладываешь кучу времени и сил в добрые дружеские советы, а в результате человек относится к такой халяве как к чему-то несерьезному. В итоге получается, что время и силы я потратил, а толковые советы выкинули в мусорку.
И я взял на себя смелость попробовать (после пары-тройки бесплатных демо консультаций) сделать это в платном серьезном формате.
Результат меня очень приятно удивил. Люди, приходящие на платные консультации, оказались очень мотивированными. Не просто на халяву послушал, поныл, пожаловался, забил и пошел дальше ныть и жаловаться.
Те, кто тратит деньги на консультацию, больше ценят всё то, что им дается, больше следуют советам, более деятельные и настроены на результат. И определенный позитивный результат они получают, что меня несказанно радует.
Сочиняешь тоже. Небось гребешь баблище, инфоцыган
Откровенно говоря, заработок с моих консультаций пока невелик. Куда больше моё сердечко греет то, что я помогаю людям разбираться с их проблемами и двигаться к лучшей жизни, чем небольшие деньги, которые я заработал.
Конечно, я надеюсь, что когда-то этот доход ощутимо вырастет, но пока что есть, то есть.
Не инфоцыганю
Так как консалтинг – это, в первую очередь, моя репутация в профессии, то я отношусь к этому очень внимательно и ответственно.
Всегда перед консультацией стараюсь понять проблему человека, чтобы прикинуть, смогу ли я ему/ей быть полезен. Никогда не беру никакой предоплаты вперед. Всегда утверждаю, что если наше общение оказалось бесполезным, я не смог никак помочь с проблемой, то могу просто не брать деньги за консультацию.
Я ценю консалтинг, как оплачиваемую помощь в решении проблем. Где-то это могут быть конкретные рецепты, где-то советы, в какую сторону копать, где-то рекомендации куда слать резюме, где-то сведение контактов с нужными людьми, потенциальными работодателями, исполнителями и т. д. Для меня главное, чтобы это была какая-то реальная помощь, чтобы человек не ушел с мыслью «блин, зря деньги потратил, ничего полезного». За безрезультатную работу не считаю этичным брать деньги (привет, остеопат, к которому я ходил прошлым летом).
Ну и реальные отзывы о своей работе так же размещаю у себя на страничке про консалтинг.
Чтобы понятно было, что примерно на консультациях творится, а при каких-то сомнениях – обратиться к моим клиентам и спросить у них, что и как, стоило ли оно того, и вообще реальный это отзыв или фейк.
Итог
Пока мне нравится то, что я делаю и куда это всё движется. Нравится, что есть хоть небольшая, но финансовая отдача (это не может не мотивировать), нравится, что люди довольны и отзываются позитивно (привет, Олег, увеличивший зп сначала в 3 раза, а потом еще в полтора). Когда рекомендуют мои услуги своим знакомым – я начинаю думать, что ну прям точно делаю это не зря🙂
В обозримом будущем напишу пост о статистике (конечно же анонимной) того, кто по каким вопросам обращается и как часто, сколько это занимает времени, чем в среднем заканчивается и т. д.
Чуть меньше года назад я анонсировал свои услуги по консалтингу https://antonov-dev.ru/consulting и сегодня хотел бы немного рассказать о том, что из этого получается.
Почему я это начал?
Помогать людям разрешать их проблемы, если у меня есть для этого необходимые знания, мне всегда нравилось. Постоянно в тех или иных комьюнити я старался отвечать людям на вопросы, давать какие-то советы, помогать по мере возможностей.
Например, еще задолго до консалтинга я в этих своих альтруистических порывах помог со сменой работы на более интересную/высокооплачиваемую примерно десятку человек.
Где-то помогал рекомендациями (если искренне мог порекомендовать человека), где-то советами куда пойти, как торговаться, сколько просить и т. д.
По мере своего профессионального развития, приобретения житейского опыта и прыгания по граблям эта потребность и возможность помогать вышла на более, так скажем, качественный уровень.
Однако появилась и проблема.
Часто, желая лучшего, вкладываешь кучу времени и сил в добрые дружеские советы, а в результате человек относится к такой халяве как к чему-то несерьезному. В итоге получается, что время и силы я потратил, а толковые советы выкинули в мусорку.
И я взял на себя смелость попробовать (после пары-тройки бесплатных демо консультаций) сделать это в платном серьезном формате.
Результат меня очень приятно удивил. Люди, приходящие на платные консультации, оказались очень мотивированными. Не просто на халяву послушал, поныл, пожаловался, забил и пошел дальше ныть и жаловаться.
Те, кто тратит деньги на консультацию, больше ценят всё то, что им дается, больше следуют советам, более деятельные и настроены на результат. И определенный позитивный результат они получают, что меня несказанно радует.
Сочиняешь тоже. Небось гребешь баблище, инфоцыган
Откровенно говоря, заработок с моих консультаций пока невелик. Куда больше моё сердечко греет то, что я помогаю людям разбираться с их проблемами и двигаться к лучшей жизни, чем небольшие деньги, которые я заработал.
Конечно, я надеюсь, что когда-то этот доход ощутимо вырастет, но пока что есть, то есть.
Не инфоцыганю
Так как консалтинг – это, в первую очередь, моя репутация в профессии, то я отношусь к этому очень внимательно и ответственно.
Всегда перед консультацией стараюсь понять проблему человека, чтобы прикинуть, смогу ли я ему/ей быть полезен. Никогда не беру никакой предоплаты вперед. Всегда утверждаю, что если наше общение оказалось бесполезным, я не смог никак помочь с проблемой, то могу просто не брать деньги за консультацию.
Я ценю консалтинг, как оплачиваемую помощь в решении проблем. Где-то это могут быть конкретные рецепты, где-то советы, в какую сторону копать, где-то рекомендации куда слать резюме, где-то сведение контактов с нужными людьми, потенциальными работодателями, исполнителями и т. д. Для меня главное, чтобы это была какая-то реальная помощь, чтобы человек не ушел с мыслью «блин, зря деньги потратил, ничего полезного». За безрезультатную работу не считаю этичным брать деньги (привет, остеопат, к которому я ходил прошлым летом).
Ну и реальные отзывы о своей работе так же размещаю у себя на страничке про консалтинг.
Чтобы понятно было, что примерно на консультациях творится, а при каких-то сомнениях – обратиться к моим клиентам и спросить у них, что и как, стоило ли оно того, и вообще реальный это отзыв или фейк.
Итог
Пока мне нравится то, что я делаю и куда это всё движется. Нравится, что есть хоть небольшая, но финансовая отдача (это не может не мотивировать), нравится, что люди довольны и отзываются позитивно (привет, Олег, увеличивший зп сначала в 3 раза, а потом еще в полтора). Когда рекомендуют мои услуги своим знакомым – я начинаю думать, что ну прям точно делаю это не зря🙂
В обозримом будущем напишу пост о статистике (конечно же анонимной) того, кто по каким вопросам обращается и как часто, сколько это занимает времени, чем в среднем заканчивается и т. д.
antonov-dev.ru
ИТ консультации
Евгений Антонов. ИТ консультации
Тимлид, делегируй!
Очень часто сталкиваюсь с неумением/нежеланием тимлидов делегировать свои вчерашние дела с прошлой должности. Особенно у начинающих ребят.
Суть проблемы
В большинстве случаев тимлид – это вчерашний хороший разработчик. Он годами писал много кода и релизил конкретные фичи.
Сегодня ему говорят: «Ты теперь тимлид и не просто точишь одну гайку как раньше, а шурупишь весь механизм. ВПЕРЕД!». В его мозгу это звучит как «делать надо еще больше, фронт работ еще шире».
В итоге он продолжает писать код и релизить важные фичи, а под вечер грустить, что менеджерские задачи никак не продвигаются.
Дальше особо ответственные понимают, что можно же просто овертаймить, чтобы уж точно всё успеть (а всё не успеешь никогда).
Это ведет к моральному и физическому истощению, выгоранию и, возможно, вчерашний хороший разработчик, уставший сегодня от такого темпа, завтра покинет компанию.
Что делать?
Одно из действенных средств – делегировать. И понимать, что вас сделали тимлидом для того, чтобы вы решали в первую очередь задачи этой позиции. Код писать может любой из ваших коллег, а тимлид – он один на команду и должен сосредоточиться на своих задачах.
Следовательно, нужно освободить себе время для этого, делегировав уже не такие важные рутинные дела другим сотрудникам.
Это поможет и вам сосредоточиться на нужной работе, и в других сотрудниках будет взращивать больше самостоятельности и ответственности: если раньше какими-то задачами занимались только вы, а теперь вы научили других, то теперь они смогут справляться сами (возможно не сразу).
Пример
Недавно консультировал свежеиспеченного тимлида. Он весь в огне, мало что успевает, делает 100% руками того, что делал, и еще хотел бы 100% лидовских дел успевать.
Порекомендовал ему побольше делегировать и сосредоточиться на той работе, для которой его и сделали лидом. В итоге рутину он делегировал, начал разгребать лидские дела, всё перестало гореть так сильно. В целом он доволен результатом 🙂
Итог
Не бойтесь чуть-чуть отпустить контроль всех на свете задач. Делегируйте, освобождайте себе время, помогайте другим расти, сосредоточьтесь на тех обязанностях, ради которых вас и сделали тимлидом.
Помните, что делегировать – это не стыдно, не зазорно, и это не перекладывание проблем на других людей. Это хорошее, полезное дело, если употребляется осознанно и добросовестно.
Не загоняйте себя и помните, что нельзя сделать все дела, которые хочется сделать. Однако можно выбрать и сделать самые важные из них.
Очень часто сталкиваюсь с неумением/нежеланием тимлидов делегировать свои вчерашние дела с прошлой должности. Особенно у начинающих ребят.
Суть проблемы
В большинстве случаев тимлид – это вчерашний хороший разработчик. Он годами писал много кода и релизил конкретные фичи.
Сегодня ему говорят: «Ты теперь тимлид и не просто точишь одну гайку как раньше, а шурупишь весь механизм. ВПЕРЕД!». В его мозгу это звучит как «делать надо еще больше, фронт работ еще шире».
В итоге он продолжает писать код и релизить важные фичи, а под вечер грустить, что менеджерские задачи никак не продвигаются.
Дальше особо ответственные понимают, что можно же просто овертаймить, чтобы уж точно всё успеть (а всё не успеешь никогда).
Это ведет к моральному и физическому истощению, выгоранию и, возможно, вчерашний хороший разработчик, уставший сегодня от такого темпа, завтра покинет компанию.
Что делать?
Одно из действенных средств – делегировать. И понимать, что вас сделали тимлидом для того, чтобы вы решали в первую очередь задачи этой позиции. Код писать может любой из ваших коллег, а тимлид – он один на команду и должен сосредоточиться на своих задачах.
Следовательно, нужно освободить себе время для этого, делегировав уже не такие важные рутинные дела другим сотрудникам.
Это поможет и вам сосредоточиться на нужной работе, и в других сотрудниках будет взращивать больше самостоятельности и ответственности: если раньше какими-то задачами занимались только вы, а теперь вы научили других, то теперь они смогут справляться сами (возможно не сразу).
Пример
Недавно консультировал свежеиспеченного тимлида. Он весь в огне, мало что успевает, делает 100% руками того, что делал, и еще хотел бы 100% лидовских дел успевать.
Порекомендовал ему побольше делегировать и сосредоточиться на той работе, для которой его и сделали лидом. В итоге рутину он делегировал, начал разгребать лидские дела, всё перестало гореть так сильно. В целом он доволен результатом 🙂
Итог
Не бойтесь чуть-чуть отпустить контроль всех на свете задач. Делегируйте, освобождайте себе время, помогайте другим расти, сосредоточьтесь на тех обязанностях, ради которых вас и сделали тимлидом.
Помните, что делегировать – это не стыдно, не зазорно, и это не перекладывание проблем на других людей. Это хорошее, полезное дело, если употребляется осознанно и добросовестно.
Не загоняйте себя и помните, что нельзя сделать все дела, которые хочется сделать. Однако можно выбрать и сделать самые важные из них.
T-shape за свой счет
Иногда ко мне за консультациями обращаются не рядовые специалисты или менеджеры, а владельцы бизнеса. В них меня очень приятно удивляет и даже восхищает их желание и умение разбираться во всём на свете, что хоть как-то связано с их бизнесом.
Это не программерский «илитный» тишейп, когда «я знаю бэкенд, могу написать вью компонент, а еще ансибл скрипт по перекладыванию файлов написал».
Это когда человек знает всё от логистики и бухучета, до ИТ и стратегии развития компании в целом.
Скорее всего, сейчас придут небожители и скажут: «Да что он там в ИТ понимает? Я вон какой класс написал, смотри, какие методы, SRP тут у меня, а еще DI и интерфейсами обмазано. Вот где тру ИТ».
Но, думаю, в целом меня поймут всё же правильно🙂
Наёмный менеджер / программист
Знает свою гаечку, её точит, не шибко хочет смотреть по сторонам.
Бывает, правда, и такое, что смотрит по сторонам, но кругозор у него искусственно ограничен. Ну смотрит он не просто на код, а на проект в целом. Уже хорошо. Тем не менее, всё, что за рамками этого проекта, скрыто, и потрогает он это вряд ли.
Владелец бизнеса
Смотрит на весь бизнес в целом, несет за него ответственность, пытается вникнуть сразу во всё на свете.
У тех людей, что обращались непосредственно ко мне, это в той или иной мере получалось. Не встречались мне пока такие овнеры, которые бы говорили: «Это фигня какая-то, разбираться в этом не хочу, сделай так, чтобы всё было зашибись. Мне наплевать, как ты это будешь делать».
Почему так?
На мой взгляд, одна из главных причин: владелец бизнеса делает всё это за свой счет, а наемные работники – за дядькины денежки.
Если что-то пойдет не так, владелец теряет свои деньги, а программист просто пойдет в другую компанию послезавтра устроится, где еще овнер не обанкротился.
Итог
Никакого мудрого итога тут нет. Просто поделился с вами своим приятным удивлением от общения с людьми такой категории. Моё искреннее уважение.
Иногда ко мне за консультациями обращаются не рядовые специалисты или менеджеры, а владельцы бизнеса. В них меня очень приятно удивляет и даже восхищает их желание и умение разбираться во всём на свете, что хоть как-то связано с их бизнесом.
Это не программерский «илитный» тишейп, когда «я знаю бэкенд, могу написать вью компонент, а еще ансибл скрипт по перекладыванию файлов написал».
Это когда человек знает всё от логистики и бухучета, до ИТ и стратегии развития компании в целом.
Скорее всего, сейчас придут небожители и скажут: «Да что он там в ИТ понимает? Я вон какой класс написал, смотри, какие методы, SRP тут у меня, а еще DI и интерфейсами обмазано. Вот где тру ИТ».
Но, думаю, в целом меня поймут всё же правильно🙂
Наёмный менеджер / программист
Знает свою гаечку, её точит, не шибко хочет смотреть по сторонам.
Бывает, правда, и такое, что смотрит по сторонам, но кругозор у него искусственно ограничен. Ну смотрит он не просто на код, а на проект в целом. Уже хорошо. Тем не менее, всё, что за рамками этого проекта, скрыто, и потрогает он это вряд ли.
Владелец бизнеса
Смотрит на весь бизнес в целом, несет за него ответственность, пытается вникнуть сразу во всё на свете.
У тех людей, что обращались непосредственно ко мне, это в той или иной мере получалось. Не встречались мне пока такие овнеры, которые бы говорили: «Это фигня какая-то, разбираться в этом не хочу, сделай так, чтобы всё было зашибись. Мне наплевать, как ты это будешь делать».
Почему так?
На мой взгляд, одна из главных причин: владелец бизнеса делает всё это за свой счет, а наемные работники – за дядькины денежки.
Если что-то пойдет не так, владелец теряет свои деньги, а программист просто пойдет в другую компанию послезавтра устроится, где еще овнер не обанкротился.
Итог
Никакого мудрого итога тут нет. Просто поделился с вами своим приятным удивлением от общения с людьми такой категории. Моё искреннее уважение.
Помни, каким ты был джуном
Иногда часто замечаю проблему в коммуникациях опытных разработчиков и джуниоров.
Матерым ребятам кажется, что всё понятно, очевидно и даже не стоит останавливаться на каких-то им понятных деталях. А молодые специалисты прям сильно за ними не успевают. И в лучшем случае они переспросят 146 раз, а в худшем просто покивают головой, скажут, что всё понятно и уйдут тихонько в угол грустить о том, как тяжело работать и какая сложная задача.
Что было со мной
Когда я был совсем джуном, мне тоже было очень тяжело просить помощи у старших товарищей. Не потому, что я стеснялся, а просто потому что я не очень хорошо схватываю информацию налету.
У меня был один коллега – очень умный чувак. Его мастерство вызывало искреннее восхищение. Даже сейчас, когда я уже стал опытнее, то всё равно считаю его тот уровень – весьма хорошим. Не знаю, что с ним сейчас, может он стал еще умнее и круче.
Но каждый раз, когда я просил у него помощи, было прям оооочень сложно. Он довольно быстро говорил и особо не парился, насколько я понимаю те или иные концепции. Просто вопрос – мгновенный ответ. Если ответ был на уровне «да или нет», то всё ок, а если он пускался в долгие размышления, то я терял мысль в первые 10 минут и дальше просто кивал как дурачок, запоминая знакомые слова. Результат такой помощи был, пожалуй, не самым продуктивным.
Что я предлагаю
Всегда нужно помнить, что ты тоже был джуном, плохо понимающим, что творится вокруг. Помнить уровень своего разумения и того, как тяжело тебе дается информация.
И если уж выпало помогать такому, то разговаривать с ним на его языке. Объяснять попроще, без наездов, уточнять, всё ли понятно, попросить объяснить своими словами, как он понял и что он планирует делать.
Джуны, бывает, с поиском элемента в двумерном массиве могут полдня просидеть, просто запутавшись, что там за индексы и кто где запрятан (это я). Не надо им без каких-либо пояснений про кворум и уровни изоляции транзакций.
Плюс скорее всего джуниор и в рамках проекта новенький. Так что он эту вашу текущую бизнес логику, сленг и прочее подобное тоже не разумеет. Добивайтесь одинаковой трактовки терминов.
Итог
Если ты старший товарищ – объясняй попроще, помни, что всё очевидное тебе не обязательно очевидно другим.
Если ты юный специалист – не стесняйся признаться, что тебе непонятно и не бойся переспросить.
Иногда часто замечаю проблему в коммуникациях опытных разработчиков и джуниоров.
Матерым ребятам кажется, что всё понятно, очевидно и даже не стоит останавливаться на каких-то им понятных деталях. А молодые специалисты прям сильно за ними не успевают. И в лучшем случае они переспросят 146 раз, а в худшем просто покивают головой, скажут, что всё понятно и уйдут тихонько в угол грустить о том, как тяжело работать и какая сложная задача.
Что было со мной
Когда я был совсем джуном, мне тоже было очень тяжело просить помощи у старших товарищей. Не потому, что я стеснялся, а просто потому что я не очень хорошо схватываю информацию налету.
У меня был один коллега – очень умный чувак. Его мастерство вызывало искреннее восхищение. Даже сейчас, когда я уже стал опытнее, то всё равно считаю его тот уровень – весьма хорошим. Не знаю, что с ним сейчас, может он стал еще умнее и круче.
Но каждый раз, когда я просил у него помощи, было прям оооочень сложно. Он довольно быстро говорил и особо не парился, насколько я понимаю те или иные концепции. Просто вопрос – мгновенный ответ. Если ответ был на уровне «да или нет», то всё ок, а если он пускался в долгие размышления, то я терял мысль в первые 10 минут и дальше просто кивал как дурачок, запоминая знакомые слова. Результат такой помощи был, пожалуй, не самым продуктивным.
Что я предлагаю
Всегда нужно помнить, что ты тоже был джуном, плохо понимающим, что творится вокруг. Помнить уровень своего разумения и того, как тяжело тебе дается информация.
И если уж выпало помогать такому, то разговаривать с ним на его языке. Объяснять попроще, без наездов, уточнять, всё ли понятно, попросить объяснить своими словами, как он понял и что он планирует делать.
Джуны, бывает, с поиском элемента в двумерном массиве могут полдня просидеть, просто запутавшись, что там за индексы и кто где запрятан (это я). Не надо им без каких-либо пояснений про кворум и уровни изоляции транзакций.
Плюс скорее всего джуниор и в рамках проекта новенький. Так что он эту вашу текущую бизнес логику, сленг и прочее подобное тоже не разумеет. Добивайтесь одинаковой трактовки терминов.
Итог
Если ты старший товарищ – объясняй попроще, помни, что всё очевидное тебе не обязательно очевидно другим.
Если ты юный специалист – не стесняйся признаться, что тебе непонятно и не бойся переспросить.
Делаю сложные дела утром
Часто замечаю, что многие люди (как и я раньше) попадают в ситуацию, когда надо бы сделать сегодня что-то сложное, но хочется сначала выполнить простенькое, разобраться с мелочами, вдохновиться легкими победами.
Я считаю это большой ошибкой. Рассмотрим две стратегии поведения: сначала легкое или сначала сложное.
Делаем сначала легкое
В этом варианте мы утром, пока еще коллеги входят в рабочий режим, спокойно, без отвлекающих факторов садимся и разгребаем легкие задачки.
Ко второй половине дня мы их разгребли и вроде как немного даже воодушевились результатами, пусть и мелкими, легко доставшимися.
А потом у нас после обеда продуктивность естественным образом снижается, плюс накапливается усталость от того, что мы уже наработали, плюс активизируются желающие или поболтать, или посовещаться (иногда это почти одно и то же), коллеги. В итоге до сложного мы доберемся ближе к концу дня и уже не в форме. Что-то, может, и начнем, потом забьем, потому что сегодня уже сложно, завтра сделаю нормально. А завтра цикл повторится с тем же результатом.
В итоге всю неделю делаем мелочевку, а серьезные вещи надкусаны, но так и не готовы.
Делаем сначала сложное
Можно утром, пока есть силы и нет отвлекающих факторов, приняться за сложную работу. Шанс, что мы её сделаем, существенно выше, чем в первом случае.
А потом ко второй половине дня, когда снижается продуктивность и мы уже сделали самое важное, можем уделить время и мелочам. Да, мы можем не успеть столько мелочей, как в первом случае. Ну так на то они и мелочи, что их можно делать атомарно, без особой когнитивной нагрузки, не сильно забуриваясь в контекст.
В итоге сделали всё важное, плюс часть мелких задачек. Если сравнивать результат с первым вариантом, то, на мой взгляд, лучше уж сложное успеть, чем выполнить больше маленьких легких вещей. Меня же в первую очередь работодатель держит, наверное, не чтобы я легкотню щелкал.
Как это выглядит у меня
Так как сейчас я в роли тимлида наполовину менеджер, а наполовину разработчик, то я беру самые когнитивно сложные задачи (внезапно это оказываются инженерные задачи, а не написание писем) и делаю их. Пишу код, проектирую архитектуру.
Во второй половине дня переключаюсь на документотворчество, созвоны, помощь коллегам по разным вопросам, согласования всякие и т. д.
Пробовал с утра делать менеджерскую работу, а после обеда разрабатывать – результат мне не понравился. Оказалось, что менеджмент я могу делать примерно одинаково производительно в любое время дня, а вот код продуктивно писать, только когда есть ментальные силы и нет регулярных отвлекающих факторов.
Итог
Мой пример, конечно, может вам и не подойти. Но попробуйте сами и посмотрите на результат.
Вдруг кому-то это правда поможет делать больше важных вещей, а в моральном плане меньше уставать и корить себя за то, что опять сегодня вон ту важную сложную штуку так и не начал, погрязнув в мелочах.
Часто замечаю, что многие люди (как и я раньше) попадают в ситуацию, когда надо бы сделать сегодня что-то сложное, но хочется сначала выполнить простенькое, разобраться с мелочами, вдохновиться легкими победами.
Я считаю это большой ошибкой. Рассмотрим две стратегии поведения: сначала легкое или сначала сложное.
Делаем сначала легкое
В этом варианте мы утром, пока еще коллеги входят в рабочий режим, спокойно, без отвлекающих факторов садимся и разгребаем легкие задачки.
Ко второй половине дня мы их разгребли и вроде как немного даже воодушевились результатами, пусть и мелкими, легко доставшимися.
А потом у нас после обеда продуктивность естественным образом снижается, плюс накапливается усталость от того, что мы уже наработали, плюс активизируются желающие или поболтать, или посовещаться (иногда это почти одно и то же), коллеги. В итоге до сложного мы доберемся ближе к концу дня и уже не в форме. Что-то, может, и начнем, потом забьем, потому что сегодня уже сложно, завтра сделаю нормально. А завтра цикл повторится с тем же результатом.
В итоге всю неделю делаем мелочевку, а серьезные вещи надкусаны, но так и не готовы.
Делаем сначала сложное
Можно утром, пока есть силы и нет отвлекающих факторов, приняться за сложную работу. Шанс, что мы её сделаем, существенно выше, чем в первом случае.
А потом ко второй половине дня, когда снижается продуктивность и мы уже сделали самое важное, можем уделить время и мелочам. Да, мы можем не успеть столько мелочей, как в первом случае. Ну так на то они и мелочи, что их можно делать атомарно, без особой когнитивной нагрузки, не сильно забуриваясь в контекст.
В итоге сделали всё важное, плюс часть мелких задачек. Если сравнивать результат с первым вариантом, то, на мой взгляд, лучше уж сложное успеть, чем выполнить больше маленьких легких вещей. Меня же в первую очередь работодатель держит, наверное, не чтобы я легкотню щелкал.
Как это выглядит у меня
Так как сейчас я в роли тимлида наполовину менеджер, а наполовину разработчик, то я беру самые когнитивно сложные задачи (внезапно это оказываются инженерные задачи, а не написание писем) и делаю их. Пишу код, проектирую архитектуру.
Во второй половине дня переключаюсь на документотворчество, созвоны, помощь коллегам по разным вопросам, согласования всякие и т. д.
Пробовал с утра делать менеджерскую работу, а после обеда разрабатывать – результат мне не понравился. Оказалось, что менеджмент я могу делать примерно одинаково производительно в любое время дня, а вот код продуктивно писать, только когда есть ментальные силы и нет регулярных отвлекающих факторов.
Итог
Мой пример, конечно, может вам и не подойти. Но попробуйте сами и посмотрите на результат.
Вдруг кому-то это правда поможет делать больше важных вещей, а в моральном плане меньше уставать и корить себя за то, что опять сегодня вон ту важную сложную штуку так и не начал, погрязнув в мелочах.