Про башню из слоновой кости и окно в реальность
Ничто не показывает наши ошибки и неверно принятые решения лучше, чем реальность. Но кто любит замечать свои ошибки? Ведь намного комфортнее априори считать все решения правильными. Один из способов – ограничивать себя безопасным «пузырём», в котором нет места негативному фидбеку о нашей работе. Но рано или поздно этот пузырь лопается и информация извне сильно демотивирует. Выход – сразу сделать реальный фидбек контролируемым.
Например, разработчикам и дизайнерам полезно видеть, как их решения используются в реальности – для этого им нужно принимать участие в саппорте, заглядывать в аналитику, смотреть за реальным поведением пользователей. Информация об ошибке в коде, упавшая в мессенжер воспринимается намного спокойнее и ей придаётся намного меньше значения, чем сообщение от реального клиента, который требует возврат денег из-за неработающей кнопки. Или который потерял деньги из-за непонятного интерфейса. И вообще, увидеть своими глазами, как реальные люди не понимают, куда нажимать в вашем инновационном интерфейсе – бесценная пощечина, приводящая в чувства.
Разработчики, работающие с реальным миром, а не только с абстракциями в коде никогда не ответят вам «у меня всё работает» в ответ на баг, ведь для них как раз важно, чтобы работало не у них. Ещё неплохо может работать использование своего же продукта. Так, например, продуктовые дизайнеры в сервисах доставки могут пойти доставлять еду, ведь одно дело – придумывать интерфейсы сидя в комфортном офисе, а другое – брать заказ на доставку где-то в пробке на велосипеде под дождём (это реальный пример).
Для менеджеров даже существует специальный термин – ivory tower syndrome, синдром «башни из слоновой кости». Такие менеджеры отдаляются от команды/подчинённых, и принимают решения основываясь только на своей картине мира, но не понимают, как всё работает в реальности, почему и с какими трудностями сталкиваются люди. Таким менеджерам нужно чаще «выходить в поля», собирать фидбек и получать информацию о том, как же работает реальность.
В общем, если вдруг вокруг появляется башня из слоновой кости – пробивайте для себя окно в реальность, через которое вы будете узнавать, как на самом деле работают ваши решения, а не как вы себе это представляли.
Ничто не показывает наши ошибки и неверно принятые решения лучше, чем реальность. Но кто любит замечать свои ошибки? Ведь намного комфортнее априори считать все решения правильными. Один из способов – ограничивать себя безопасным «пузырём», в котором нет места негативному фидбеку о нашей работе. Но рано или поздно этот пузырь лопается и информация извне сильно демотивирует. Выход – сразу сделать реальный фидбек контролируемым.
Например, разработчикам и дизайнерам полезно видеть, как их решения используются в реальности – для этого им нужно принимать участие в саппорте, заглядывать в аналитику, смотреть за реальным поведением пользователей. Информация об ошибке в коде, упавшая в мессенжер воспринимается намного спокойнее и ей придаётся намного меньше значения, чем сообщение от реального клиента, который требует возврат денег из-за неработающей кнопки. Или который потерял деньги из-за непонятного интерфейса. И вообще, увидеть своими глазами, как реальные люди не понимают, куда нажимать в вашем инновационном интерфейсе – бесценная пощечина, приводящая в чувства.
Разработчики, работающие с реальным миром, а не только с абстракциями в коде никогда не ответят вам «у меня всё работает» в ответ на баг, ведь для них как раз важно, чтобы работало не у них. Ещё неплохо может работать использование своего же продукта. Так, например, продуктовые дизайнеры в сервисах доставки могут пойти доставлять еду, ведь одно дело – придумывать интерфейсы сидя в комфортном офисе, а другое – брать заказ на доставку где-то в пробке на велосипеде под дождём (это реальный пример).
Для менеджеров даже существует специальный термин – ivory tower syndrome, синдром «башни из слоновой кости». Такие менеджеры отдаляются от команды/подчинённых, и принимают решения основываясь только на своей картине мира, но не понимают, как всё работает в реальности, почему и с какими трудностями сталкиваются люди. Таким менеджерам нужно чаще «выходить в поля», собирать фидбек и получать информацию о том, как же работает реальность.
В общем, если вдруг вокруг появляется башня из слоновой кости – пробивайте для себя окно в реальность, через которое вы будете узнавать, как на самом деле работают ваши решения, а не как вы себе это представляли.
Про неопределённость
Многие ошибочно считают, что senior-специалистов отличает то, что они всегда уверены в том, что и как нужно делать. Что senior-специалисты строят абсолютно понятные и предсказуемые системы и процессы, но в быстро развивающихся продуктах и командах это невозможно. Никто в команде не может точно сказать, что нужно делать, как и какие потребуются ресурсы и сколько времени это займёт, можно лишь догадываться. На самом деле senior-специалисты принимают во внимание неопредлённость и свои незнания (и неопределённость и незнания людей вокруг) и строят системы и процессы с их учетом. Они понимают, что их оценки могут быть неверны, что код может сломаться, а люди их могут их понять неправильно.
Например, опытные product-менеджеры не просто приоритезируют новые фичи и гипотезы по их важности/деньгам/тону, с которым гипотеза была озвучена начальством. Они учитывают свою же уверенность в этих оценках (см. confidence в RICE).
Опытные разработчики чаще стараются удалять код, чем писать, чтобы уменьшать сложность систем и увеличивать их предсказуемость, а когда добавляют что-то новое – со всех сторон обкладываются мониторингами и алертами, ведь за свои 5/10/15 лет в разработке они поняли, что даже идеально написанный и протестированный код может сломаться у клиента и часто даже не по их вине.
Неопытный проджект-менеджер закидывает разработчикам новую фичу на оценку и ожидает точного срока, при несоблюдении которого будет приходить и спрашивать, а почему не уложились в свою же оценку? Опытный же понимает, что разработчики сами могут не знать, сколько может занять эта новая фича и узнает не срок, когда фича будет на продакшене, а срок, когда у разработчика будет достаточно данных, чтобы дать более-менее правильную оценку (а ещё лучше – работает без оценок). Кстати, некоторые системы ведения проектов построены вокруг идеи того, что на первой стадии работы над проектом мы не делаем ничего «осязаемого», мы просто уменьшаем количество unknowns о проекте, а во второй уже что-то делаем (см. hill charts в Basecamp).
В общем, не ожидайте, что всё, что вы делаете – правильно. Лучше заранее подумайте, как вы сможете как можно раньше понять, что сделали что-то неправильно?
Многие ошибочно считают, что senior-специалистов отличает то, что они всегда уверены в том, что и как нужно делать. Что senior-специалисты строят абсолютно понятные и предсказуемые системы и процессы, но в быстро развивающихся продуктах и командах это невозможно. Никто в команде не может точно сказать, что нужно делать, как и какие потребуются ресурсы и сколько времени это займёт, можно лишь догадываться. На самом деле senior-специалисты принимают во внимание неопредлённость и свои незнания (и неопределённость и незнания людей вокруг) и строят системы и процессы с их учетом. Они понимают, что их оценки могут быть неверны, что код может сломаться, а люди их могут их понять неправильно.
Например, опытные product-менеджеры не просто приоритезируют новые фичи и гипотезы по их важности/деньгам/тону, с которым гипотеза была озвучена начальством. Они учитывают свою же уверенность в этих оценках (см. confidence в RICE).
Опытные разработчики чаще стараются удалять код, чем писать, чтобы уменьшать сложность систем и увеличивать их предсказуемость, а когда добавляют что-то новое – со всех сторон обкладываются мониторингами и алертами, ведь за свои 5/10/15 лет в разработке они поняли, что даже идеально написанный и протестированный код может сломаться у клиента и часто даже не по их вине.
Неопытный проджект-менеджер закидывает разработчикам новую фичу на оценку и ожидает точного срока, при несоблюдении которого будет приходить и спрашивать, а почему не уложились в свою же оценку? Опытный же понимает, что разработчики сами могут не знать, сколько может занять эта новая фича и узнает не срок, когда фича будет на продакшене, а срок, когда у разработчика будет достаточно данных, чтобы дать более-менее правильную оценку (а ещё лучше – работает без оценок). Кстати, некоторые системы ведения проектов построены вокруг идеи того, что на первой стадии работы над проектом мы не делаем ничего «осязаемого», мы просто уменьшаем количество unknowns о проекте, а во второй уже что-то делаем (см. hill charts в Basecamp).
В общем, не ожидайте, что всё, что вы делаете – правильно. Лучше заранее подумайте, как вы сможете как можно раньше понять, что сделали что-то неправильно?
Эволюция мотивации менеджера
Работа менеджера и мотивация часто встречаются в одном предложении. Но в 90% случаев это предложение о том, что менеджеры должны мотивировать свою команду. Но как им мотивировать себя?
Когда я был разработчиком, меня всегда заряжали оживающие системы. Я мог уйти в состояние потока, нацепить наушники, включить звук на всю и за день или ночь закончить большой проект. В итоге я понимал – it's alive! Что-то можно увидеть, потрогать руками, оценить. Ложился спать с чувством выполненного долга, а утром уже искал новую задачу, чтобы снова это испытать. И так по кругу.
Потом моя роль сместилась в сторону «играющего тренера». Моя мотивация не изменилась – я продолжал кайфовать от оживающих систем, сделанных моими руками. Но моё время начала отбирать «ненастоящая работа» – встречи, планирования, собеседования, 1:1. Всё то, в результате чего я не создавал чего-то нового. Осязаемых результатов становилось всё меньше. Ненастоящей работы всё больше и из-за этого падала мотивация – постоянно хотелось отложить менеджерство и пойти что-то сделать руками.
Думаю, с такой ситуацией сталкиваются многие, переходящие из разработки или дизайна в менеджмент.
Как менять мышление?
Во-первых, нужно совершить переход от идеи «кайф, когда я сделал X» к «кайф, когда я помог людям сделать X». Задача менеджера тут – помогать команде со всех сторон. Нужна реорганизация процессов? Кажется, что люди не понимают друг друга? Нужно больше людей? Можно брать и заниматься этим, чтобы привести команду к желаемому результату.
Если провести аналогию между командой и двигателем, то задача менеджера – собрать все необходимые детали, поставить их в правильные места, отладить связь друг с другом. И начать регулярно менять масло. Самое сложное тут – не делать всё самому, а помогать делать другим.
В таком случае можно считать себя причастным к чужому результату. И да, в конечном итоге нужно начать немного паразитировать и научиться получать свой дофамин за счёт чужой работы.
Во-вторых, у менеджеров этого самого дофамина может быть больше, ведь команда (или команды) могут производить результатов намного больше и намного быстрее, чем одни руки. Главное – учиться замечать чужие результаты (а иногда это сложно, ведь многие просто не любят хвалиться своей работой). Также полезно, об этих результатах рассказывать всем вокруг.
В-третьих, можно заметить, что кроме результатов, которые можно потрогать и увидеть у менеджеров появляются новые, более эфемерные. Например, развитие сотрудников. Когда ты помогаешь информацией, фидбеком и подбором задач под нужды людей ты видишь, как быстро они растут.
Главное правило в поиске мотивации для менеджера – любой быстрый дофамин, большинство срочных маленьких дел отдаляют вас (и вашу команду) от больших результатов. Чем больше людей с вами работают, тем более отдалёнными будут результаты вашей работы и тем более не срочные и сложные задачи нужно выбирать.
В общем, занимайтесь тем, от чего вы кайфуете – люди намного продуктивнее, когда делают то, что им хочется, а не то, что нужно. Но идеально, когда это одно и тоже.
---
Поразмышлять о том, как менеджерам мотивировать себя мы договорились с Александром Кузовлевым, автором канала На шаг впереди, у которого в этом большой опыт – он руководил в качестве PM и CTO в нескольких стартапах. Его пост на эту тему читайте тут:
👉Как менеджеру мотивировать себя, если не видно прямого результата его работы?👈
Работа менеджера и мотивация часто встречаются в одном предложении. Но в 90% случаев это предложение о том, что менеджеры должны мотивировать свою команду. Но как им мотивировать себя?
Когда я был разработчиком, меня всегда заряжали оживающие системы. Я мог уйти в состояние потока, нацепить наушники, включить звук на всю и за день или ночь закончить большой проект. В итоге я понимал – it's alive! Что-то можно увидеть, потрогать руками, оценить. Ложился спать с чувством выполненного долга, а утром уже искал новую задачу, чтобы снова это испытать. И так по кругу.
Потом моя роль сместилась в сторону «играющего тренера». Моя мотивация не изменилась – я продолжал кайфовать от оживающих систем, сделанных моими руками. Но моё время начала отбирать «ненастоящая работа» – встречи, планирования, собеседования, 1:1. Всё то, в результате чего я не создавал чего-то нового. Осязаемых результатов становилось всё меньше. Ненастоящей работы всё больше и из-за этого падала мотивация – постоянно хотелось отложить менеджерство и пойти что-то сделать руками.
Думаю, с такой ситуацией сталкиваются многие, переходящие из разработки или дизайна в менеджмент.
Как менять мышление?
Во-первых, нужно совершить переход от идеи «кайф, когда я сделал X» к «кайф, когда я помог людям сделать X». Задача менеджера тут – помогать команде со всех сторон. Нужна реорганизация процессов? Кажется, что люди не понимают друг друга? Нужно больше людей? Можно брать и заниматься этим, чтобы привести команду к желаемому результату.
Если провести аналогию между командой и двигателем, то задача менеджера – собрать все необходимые детали, поставить их в правильные места, отладить связь друг с другом. И начать регулярно менять масло. Самое сложное тут – не делать всё самому, а помогать делать другим.
В таком случае можно считать себя причастным к чужому результату. И да, в конечном итоге нужно начать немного паразитировать и научиться получать свой дофамин за счёт чужой работы.
Во-вторых, у менеджеров этого самого дофамина может быть больше, ведь команда (или команды) могут производить результатов намного больше и намного быстрее, чем одни руки. Главное – учиться замечать чужие результаты (а иногда это сложно, ведь многие просто не любят хвалиться своей работой). Также полезно, об этих результатах рассказывать всем вокруг.
В-третьих, можно заметить, что кроме результатов, которые можно потрогать и увидеть у менеджеров появляются новые, более эфемерные. Например, развитие сотрудников. Когда ты помогаешь информацией, фидбеком и подбором задач под нужды людей ты видишь, как быстро они растут.
Главное правило в поиске мотивации для менеджера – любой быстрый дофамин, большинство срочных маленьких дел отдаляют вас (и вашу команду) от больших результатов. Чем больше людей с вами работают, тем более отдалёнными будут результаты вашей работы и тем более не срочные и сложные задачи нужно выбирать.
В общем, занимайтесь тем, от чего вы кайфуете – люди намного продуктивнее, когда делают то, что им хочется, а не то, что нужно. Но идеально, когда это одно и тоже.
---
Поразмышлять о том, как менеджерам мотивировать себя мы договорились с Александром Кузовлевым, автором канала На шаг впереди, у которого в этом большой опыт – он руководил в качестве PM и CTO в нескольких стартапах. Его пост на эту тему читайте тут:
👉Как менеджеру мотивировать себя, если не видно прямого результата его работы?👈
Про конференции
За время ограничений и локдаунов я успел побывать в роли участника на нескольких онлайн конференциях. В итоге я понял, что если для образовательных целей такой формат и подходит, то неформальное общение и нетворкинг в кулуарах сложно организовать по зуму, в отличии от оффлайна. Хорошо, что оффлайн конференции ожили. Например, во второй половине марта пройдёт TeamLead Conf в Москве – го общаться.
А если вы менеджер или тим-лид, то вам наверняка есть, что рассказать о вашей работе. Для вас у меня есть 2 новости:
– Уже подано более 70 заявок на доклады, митапы и круглые столы, они продолжают поступать, но вы ещё успеваете подать заявку на доклад. Торопитесь присоединиться к самой масштабной тусовке тимлидов.
– Программный комитет готов помогать определиться с темой доклада или мастер-класса, помочь подготовить сам доклад или презентацию. Так что, если вы точно знаете, что хотите поделиться чем-то очень нужным и важным, но не знаете, с какой стороны подойти - пишите смело им, они помогут.
Формально всё описано здесь https://tlconf.info. Или пишите в личку руководителю программного комитета @dumtest.
За время ограничений и локдаунов я успел побывать в роли участника на нескольких онлайн конференциях. В итоге я понял, что если для образовательных целей такой формат и подходит, то неформальное общение и нетворкинг в кулуарах сложно организовать по зуму, в отличии от оффлайна. Хорошо, что оффлайн конференции ожили. Например, во второй половине марта пройдёт TeamLead Conf в Москве – го общаться.
А если вы менеджер или тим-лид, то вам наверняка есть, что рассказать о вашей работе. Для вас у меня есть 2 новости:
– Уже подано более 70 заявок на доклады, митапы и круглые столы, они продолжают поступать, но вы ещё успеваете подать заявку на доклад. Торопитесь присоединиться к самой масштабной тусовке тимлидов.
– Программный комитет готов помогать определиться с темой доклада или мастер-класса, помочь подготовить сам доклад или презентацию. Так что, если вы точно знаете, что хотите поделиться чем-то очень нужным и важным, но не знаете, с какой стороны подойти - пишите смело им, они помогут.
Формально всё описано здесь https://tlconf.info. Или пишите в личку руководителю программного комитета @dumtest.
Что развивать лидеру?
Частый кейс в IT, когда в команде «самый умный» становится руководителем. Например, программист тим-лидом, дизайнер – арт-директором. Но часто такие тим-лиды и арт-директора (как и те, кто их назначает) забывают, что при переходе в менеджмент даже самый rock-star-senior-ниндзя-staff-специалист становится junior-менеджером. И после перехода нужно развивать не столько hard-скилы в своём деле, сколько (как бы банально это не звучало) – лидерские качества.
Так что это за качества такие? Мне больше всего нравится типология, в которой все навыки можно разделить на 3 группы:
1. Интеллектуальное лидерство
Эта группа навыков развита у «самых умных» – им верят, потому что они крутые специалисты. Но нужно смириться, что перейдя в менеджмент нельзя всегда оставаться лучшим. Те, кто регулярно делают вещи своими руками, следят за индустрией и прокачивают hard-скилы быстро вас обгонят. Вам же нужно научиться доверять и делегировать, а самому прокачивать другие 2 типа лидерства, а интеллект проявлять в общих подходах к решению проблем, понимании соседних областей и общей картины, принятии стратегических решений.
2. Организационное лидерство
Проявляется в том, что менеджер может собрать людей и построить процессы так, что команда начинает функционировать, как хорошо отлаженная система (а желательно ещё и так, чтобы эти процессы никого не бесили). Он решает в команде проблемы коммуникаций, шаринга знаний, уменьшает bus-фактор, заранее понимает, где образуются бутылочные горлышки и решает эти проблемы, чтобы команда могла сфокусировано достигать своих целей.
3. Эмоциональное лидерство
Проявляется в том, что менеджер понимает мотивацию разных участников команды, умеет искать подход к разным людям, замечает упадок сил и признаки выгорания у членов команды и может заранее переключить на другие задачи или напомнить про отпуск. Умеет объяснить людям, в чём польза от их работы и на какие большие цели и задачи влияет их труд, управляет уровнем энергии и эмоциональным фоном в команде, разруливает конфликты (как внутренние, так и межкомандные).
Рекомендация сегодня одна: отличный TedTalk на тему эмоционального лидерства: Simon Sinek: How great leaders inspire action.
Частый кейс в IT, когда в команде «самый умный» становится руководителем. Например, программист тим-лидом, дизайнер – арт-директором. Но часто такие тим-лиды и арт-директора (как и те, кто их назначает) забывают, что при переходе в менеджмент даже самый rock-star-senior-ниндзя-staff-специалист становится junior-менеджером. И после перехода нужно развивать не столько hard-скилы в своём деле, сколько (как бы банально это не звучало) – лидерские качества.
Так что это за качества такие? Мне больше всего нравится типология, в которой все навыки можно разделить на 3 группы:
1. Интеллектуальное лидерство
Эта группа навыков развита у «самых умных» – им верят, потому что они крутые специалисты. Но нужно смириться, что перейдя в менеджмент нельзя всегда оставаться лучшим. Те, кто регулярно делают вещи своими руками, следят за индустрией и прокачивают hard-скилы быстро вас обгонят. Вам же нужно научиться доверять и делегировать, а самому прокачивать другие 2 типа лидерства, а интеллект проявлять в общих подходах к решению проблем, понимании соседних областей и общей картины, принятии стратегических решений.
2. Организационное лидерство
Проявляется в том, что менеджер может собрать людей и построить процессы так, что команда начинает функционировать, как хорошо отлаженная система (а желательно ещё и так, чтобы эти процессы никого не бесили). Он решает в команде проблемы коммуникаций, шаринга знаний, уменьшает bus-фактор, заранее понимает, где образуются бутылочные горлышки и решает эти проблемы, чтобы команда могла сфокусировано достигать своих целей.
3. Эмоциональное лидерство
Проявляется в том, что менеджер понимает мотивацию разных участников команды, умеет искать подход к разным людям, замечает упадок сил и признаки выгорания у членов команды и может заранее переключить на другие задачи или напомнить про отпуск. Умеет объяснить людям, в чём польза от их работы и на какие большие цели и задачи влияет их труд, управляет уровнем энергии и эмоциональным фоном в команде, разруливает конфликты (как внутренние, так и межкомандные).
Рекомендация сегодня одна: отличный TedTalk на тему эмоционального лидерства: Simon Sinek: How great leaders inspire action.
Всё сделали не так
Признавайтесь, сколько раз вы понимали, что вокруг вас всё сделано неправильно, а вы то точно знали, как нужно было делать? Процессы не те и вот если бы вы участвовали в их формировании – точно всё работало бы лучше. Код – ужасное легаси и вообще надо было другие технологии использовать. Работать вам приходится с некомпетентными людьми, но вот если бы вы занимались наймом – наняли бы правильных.
Проблема в том, что ретроспективно судить конечно проще (снова привет, когнитивные искажения). Ведь так не видно, как конечный продукт (команда, код, процесс) оказался в этой точке, какие решения и кем были приняты, какие были условия и ограничения. Но важнее другое: ценность людей для бизнеса не в знании, «как нужно было сделать», а в действиях здесь и сейчас.
Конечно, разработчику удобнее работать в неспешном темпе, когда есть время спроектировать сложную систему и всегда есть время на технический долг. Но ценным его делает умение понять требования бизнеса и в нужной ситуации наговнокодить, а в другой заложить время на проектирование и реализацию гибкой и стабильной системы. Так же как и умение не только писать проект хорошо с нуля, но и поддерживать и улучшать уже работающие решения.
Менеджеру будет комфортнее работать с крутыми мотивированными людьми, которые сами разбираются в том, что нужно сделать, предлагают решения, понимают друг друга с полуслова и общаются с другими отделами. Но какая от этого польза бизнесу, если сейчас команда не такая? Важнее то, что менеджер понимает, что делать сейчас, чтобы команда становилась лучше.
В общем, если знаете, как нужно было делать – классно. Сейчас то что делать?
Признавайтесь, сколько раз вы понимали, что вокруг вас всё сделано неправильно, а вы то точно знали, как нужно было делать? Процессы не те и вот если бы вы участвовали в их формировании – точно всё работало бы лучше. Код – ужасное легаси и вообще надо было другие технологии использовать. Работать вам приходится с некомпетентными людьми, но вот если бы вы занимались наймом – наняли бы правильных.
Проблема в том, что ретроспективно судить конечно проще (снова привет, когнитивные искажения). Ведь так не видно, как конечный продукт (команда, код, процесс) оказался в этой точке, какие решения и кем были приняты, какие были условия и ограничения. Но важнее другое: ценность людей для бизнеса не в знании, «как нужно было сделать», а в действиях здесь и сейчас.
Конечно, разработчику удобнее работать в неспешном темпе, когда есть время спроектировать сложную систему и всегда есть время на технический долг. Но ценным его делает умение понять требования бизнеса и в нужной ситуации наговнокодить, а в другой заложить время на проектирование и реализацию гибкой и стабильной системы. Так же как и умение не только писать проект хорошо с нуля, но и поддерживать и улучшать уже работающие решения.
Менеджеру будет комфортнее работать с крутыми мотивированными людьми, которые сами разбираются в том, что нужно сделать, предлагают решения, понимают друг друга с полуслова и общаются с другими отделами. Но какая от этого польза бизнесу, если сейчас команда не такая? Важнее то, что менеджер понимает, что делать сейчас, чтобы команда становилась лучше.
В общем, если знаете, как нужно было делать – классно. Сейчас то что делать?
Поучаствовал в создании небольшого тренажера для проджект-менеджеров вместе со @skillsetter. Если у вас всё давно идеально работает и своих проблем не хватает – попробуйте решить чужие кейсы;)
👉 Тренажер
👉 Тренажер
skillsetter.io
Тестовые задания по проджект-менеджменту: тренажер для подготовки к собеседованию
Тестовые задания для проджект менеджера: кейсы, которые дают менеджерам IT-проектов на собеседовании. Задания на эстимейт проекта, решение конфликтов и проведение kick-off.
Про крутышей
Недавно на сессии менторства меня спросили – что отличает senior разработчиков? Одна из моих идей в том, что крутыши в своём деле не просто умеют что-то делать, а делают стабильно круто.
У вас же наверняка есть люди в окружении, которые вне зависимости от условий в 99% случаев делают качественно? И не важно, какие дедлайны, какая команда, какой уровень неопределенности в задаче, какие инструменты они будут использовать – результат точно будет крутым.
Конечно, этот скилл можно декомпозировать и говорить, что синьоров отличает насмотренность, опыт в конкретных технологиях или инструментах, глубокое погружение в задачи, стратегическое мышление, но в итоге всё сложится именно в стабильно крутые результаты. В общем, синьорность – это про марафон, а не спринт. Помните про людей, которые могут сделать хорошо, а есть те, которые не могут делать плохо?
В общем, задумываетесь, что вам нужно прокачивать, чтобы вырасти? Подумайте, что вам в последнее время мешало делать стабильно классно – это и есть зона роста.
P.S. Кстати, записывайтесь ко мне на менторство через getmentor. Личные консультации пока бесплатные!
Недавно на сессии менторства меня спросили – что отличает senior разработчиков? Одна из моих идей в том, что крутыши в своём деле не просто умеют что-то делать, а делают стабильно круто.
У вас же наверняка есть люди в окружении, которые вне зависимости от условий в 99% случаев делают качественно? И не важно, какие дедлайны, какая команда, какой уровень неопределенности в задаче, какие инструменты они будут использовать – результат точно будет крутым.
Конечно, этот скилл можно декомпозировать и говорить, что синьоров отличает насмотренность, опыт в конкретных технологиях или инструментах, глубокое погружение в задачи, стратегическое мышление, но в итоге всё сложится именно в стабильно крутые результаты. В общем, синьорность – это про марафон, а не спринт. Помните про людей, которые могут сделать хорошо, а есть те, которые не могут делать плохо?
В общем, задумываетесь, что вам нужно прокачивать, чтобы вырасти? Подумайте, что вам в последнее время мешало делать стабильно классно – это и есть зона роста.
P.S. Кстати, записывайтесь ко мне на менторство через getmentor. Личные консультации пока бесплатные!
Т.к. у меня в канале много продактов и разработчиков мобильных приложений, поделюсь анонсом. Мы в Appbooster делаем сервис для проверки продуктовых гипотез в мобильных приложениях Proba. С его помощью можно запускать A/B-тесты, а мы будем использовать байесовскую статистику, чтобы оптимизировать трафик под выбранную целевую метрику (например, конверсии или ARPU).
Cегодня команда проекта приглашает всех желающих на бесплатный вебинар «А/B-тесты в мобайле: как проверять гипотезы быстро и дешево».
Сегодня, 1 декабря в 16:00 МСК. Регистрация доступна здесь.
Cегодня команда проекта приглашает всех желающих на бесплатный вебинар «А/B-тесты в мобайле: как проверять гипотезы быстро и дешево».
Сегодня, 1 декабря в 16:00 МСК. Регистрация доступна здесь.
Про сложность и размер
В универе я получил один абсолютно бесполезный для современного мира навык: писать много и говорить сложно. Ведь если ты пишешь курсовую, реферат или диплом – у тебя обязательно есть ограничение по количеству страниц. Если объяснить свою мысль на паре листов А4, используя формулировки, которые поймут даже дети – тебя обязательно пошлют переделывать, ведь это не серьезно. Такой вот анти-метод Фейнмана.
Но в реальном, не академическом мире, у всех куча дел и людям просто некогда читать ваши портянки. Если захотите что-то рассказать соседнему отделу и напишете для этого длинное сообщение – его просто не дочитают. Если вы сложно объясните свою идею команде/руководителю – с большой вероятностью её не возьмут в работу.
Ещё из разработки я запомнил: если код получается слишком сложный – мы делаем что-то не так. Причем иногда проблема где-то на другом этапе, не в коде (а в проектировании, в дизайне, в самой идее новой фичи). Этот триггер можно использовать для всего: если у вас получается сложный/непонятный процесс, письмо, отчёт – в нём что-то не так, надо порефакторить.
В общем, хотите повысить конверсию людей в действия? Не отнимайте у них много времени и объясняйте проще, что вы от них хотите.
В универе я получил один абсолютно бесполезный для современного мира навык: писать много и говорить сложно. Ведь если ты пишешь курсовую, реферат или диплом – у тебя обязательно есть ограничение по количеству страниц. Если объяснить свою мысль на паре листов А4, используя формулировки, которые поймут даже дети – тебя обязательно пошлют переделывать, ведь это не серьезно. Такой вот анти-метод Фейнмана.
Но в реальном, не академическом мире, у всех куча дел и людям просто некогда читать ваши портянки. Если захотите что-то рассказать соседнему отделу и напишете для этого длинное сообщение – его просто не дочитают. Если вы сложно объясните свою идею команде/руководителю – с большой вероятностью её не возьмут в работу.
Ещё из разработки я запомнил: если код получается слишком сложный – мы делаем что-то не так. Причем иногда проблема где-то на другом этапе, не в коде (а в проектировании, в дизайне, в самой идее новой фичи). Этот триггер можно использовать для всего: если у вас получается сложный/непонятный процесс, письмо, отчёт – в нём что-то не так, надо порефакторить.
В общем, хотите повысить конверсию людей в действия? Не отнимайте у них много времени и объясняйте проще, что вы от них хотите.
Про проактивность
Многие компании и менеджеры топят за то, что нужно нанимать проактивных людей. А что это такое – мало кто говорит. Поделюсь своим мнением: проактивность – это не работать ради работы. Не работать больше часов, чем ожидается. Это не наводить суету вокруг. Это даже не делать больше, чем нужно. Проактивность - это видеть проблемы и придумывать их решения. Но не ваши проблемы, а проблемы бизнеса, коллег, менеджера, клиентов. Это понимать, что нужно людям и давать им это.
Приятным бонусом к проактивности идёт свобода действий:
– Если разработчик рассказывает, что он делает и какие у него проблемы – менеджеры не докучают ему вопросом «ну че, когда будет готово?».
– Если менеджер предоставляет руководителю в отчете всю нужную информацию о проекте/команде – руководитель не будет навязывать свой формат отчёта или процесс, его проблему уже решили.
– Если разработчик пишет код для других разработчиков, а не для машины, заботится о читаемости и объясняет непонятные места – ему не нужно тратить время на ответы другим разработчиком во время ревью, а апрув он получает быстрее.
– Если дизайнер объяснил свою идею текстом/стикерами/схемами на макетах, а не просто скинул картинки – команде не придётся назначать звонок «обсуждаем новые макеты», а дизайнер этот час времени будет заниматься любимыми делами.
В любом разговоре про проактивность никуда без байки про барина и работников. Знаю, вы пойдёте гуглить, так что сэкономлю ваше время:
Приходит работник к барину и говорит: «Барин, скажи, почему ты Семёну такому же работнику платишь 5 рублей в день всегда, а мне только 5 копеек?». Барин говорит: «Садись, сейчас объясню. Ой, смотри, за окном телега едет. Сбегай и спроси, не сено ли везут». Работник сбегал и говорит: «Да, сено везут». Барин опять говорит: «А ты спросил с каких лугов везут? С Семёновских?». Работник: «Не знаю». Барин: «Ну, сходи спроси». Работник сходил. Пришёл и говорит: «С Семёновских». Барин опять спрашивает: «А какой покос? Первый или второй?». Работник опять побежал спрашивать. Пришёл и ответил, что первый. Барин опять: «Почем они будут продавать?». Работник опять не знал ответа на этот вопрос. Хотел бежать спрашивать.*
В этот момент заходит Семён и говорит: «Барин, там сено везут с Семёновских лугов первого покоса, стоит 5 рублей, но я уже сторговался на 3. И пока телегу завернул, она стоит в нашем дворе. Что дальше делать будем?».
В общем, будьте как Семён. Качайте проактивность.
Многие компании и менеджеры топят за то, что нужно нанимать проактивных людей. А что это такое – мало кто говорит. Поделюсь своим мнением: проактивность – это не работать ради работы. Не работать больше часов, чем ожидается. Это не наводить суету вокруг. Это даже не делать больше, чем нужно. Проактивность - это видеть проблемы и придумывать их решения. Но не ваши проблемы, а проблемы бизнеса, коллег, менеджера, клиентов. Это понимать, что нужно людям и давать им это.
Приятным бонусом к проактивности идёт свобода действий:
– Если разработчик рассказывает, что он делает и какие у него проблемы – менеджеры не докучают ему вопросом «ну че, когда будет готово?».
– Если менеджер предоставляет руководителю в отчете всю нужную информацию о проекте/команде – руководитель не будет навязывать свой формат отчёта или процесс, его проблему уже решили.
– Если разработчик пишет код для других разработчиков, а не для машины, заботится о читаемости и объясняет непонятные места – ему не нужно тратить время на ответы другим разработчиком во время ревью, а апрув он получает быстрее.
– Если дизайнер объяснил свою идею текстом/стикерами/схемами на макетах, а не просто скинул картинки – команде не придётся назначать звонок «обсуждаем новые макеты», а дизайнер этот час времени будет заниматься любимыми делами.
В любом разговоре про проактивность никуда без байки про барина и работников. Знаю, вы пойдёте гуглить, так что сэкономлю ваше время:
Приходит работник к барину и говорит: «Барин, скажи, почему ты Семёну такому же работнику платишь 5 рублей в день всегда, а мне только 5 копеек?». Барин говорит: «Садись, сейчас объясню. Ой, смотри, за окном телега едет. Сбегай и спроси, не сено ли везут». Работник сбегал и говорит: «Да, сено везут». Барин опять говорит: «А ты спросил с каких лугов везут? С Семёновских?». Работник: «Не знаю». Барин: «Ну, сходи спроси». Работник сходил. Пришёл и говорит: «С Семёновских». Барин опять спрашивает: «А какой покос? Первый или второй?». Работник опять побежал спрашивать. Пришёл и ответил, что первый. Барин опять: «Почем они будут продавать?». Работник опять не знал ответа на этот вопрос. Хотел бежать спрашивать.*
В этот момент заходит Семён и говорит: «Барин, там сено везут с Семёновских лугов первого покоса, стоит 5 рублей, но я уже сторговался на 3. И пока телегу завернул, она стоит в нашем дворе. Что дальше делать будем?».
В общем, будьте как Семён. Качайте проактивность.
Про делегирование
1. Все задачи, которыми я занимаюсь очень важны. Я не могу от них отказываться.
2. Нужно быть очень ответственным, чтобы их выполнять. У нас пока нет другого такого человека, кроме меня.
3. Описывать задачу и погружать другого человека в контекст дольше, чем сделать самому.
Какая из этих мыслей регулярно крутится у вас в голове? Если хотя бы одна из трёх – поздравляю, вам нужно учиться делегировать. Например, почитать гайд от @skillsetter, в котором я поделился полезным лайфхаком:
Делегирование задач: зачем это делать, как правильно и что мешает
Кстати, если у вас есть свои лайфхаки или инструменты делегирования – закидывайте в комменты.
1. Все задачи, которыми я занимаюсь очень важны. Я не могу от них отказываться.
2. Нужно быть очень ответственным, чтобы их выполнять. У нас пока нет другого такого человека, кроме меня.
3. Описывать задачу и погружать другого человека в контекст дольше, чем сделать самому.
Какая из этих мыслей регулярно крутится у вас в голове? Если хотя бы одна из трёх – поздравляю, вам нужно учиться делегировать. Например, почитать гайд от @skillsetter, в котором я поделился полезным лайфхаком:
Делегирование задач: зачем это делать, как правильно и что мешает
Кстати, если у вас есть свои лайфхаки или инструменты делегирования – закидывайте в комменты.
Telegram
skillsetter.io
Про кар'єру в IT, запуск і зростання продуктів.
Про правильные привычки в разработке
Разработка – командная дисциплина, где важен не только код и результат, но и процесс. Поэтому для разработчиков полезно вырабатывать правильные привычки. Попробовал сформулировать 5 таких привычек, которые упростят жизнь всем вокруг:
1. Работать прозрачно
2. Двигаться по чуть-чуть
3. Говорить просто
4. Делать скучно
5. Соблюдать баланс
Подробности про каждый принцип - в статье, которуя я написал для @skillbox_media_code
Разработка – командная дисциплина, где важен не только код и результат, но и процесс. Поэтому для разработчиков полезно вырабатывать правильные привычки. Попробовал сформулировать 5 таких привычек, которые упростят жизнь всем вокруг:
1. Работать прозрачно
2. Двигаться по чуть-чуть
3. Говорить просто
4. Делать скучно
5. Соблюдать баланс
Подробности про каждый принцип - в статье, которуя я написал для @skillbox_media_code
Новый год в канале решил начать с подведения итогов предыдущего, а с вами поделюсь постами за прошлый год, которые собрали больше всего пересылок. Будет полезно для недавно подписавшихся:
1. Time-to метрики
2. Что развивать лидеру?
3. Про неопределённость
4. Про проактивность
5. Про объяснения
1. Time-to метрики
2. Что развивать лидеру?
3. Про неопределённость
4. Про проактивность
5. Про объяснения
Telegram
Saturday Night Hack
Time-to метрики
Все знают про метрику time-to-market, которая по-сути отражает скорость разработки. Чем медленнее мы будем выкатывать гипотезы – тем с большей вероятностью нас обгонят конкуренты или мы просто потратим все деньги на команду и не найдём product…
Все знают про метрику time-to-market, которая по-сути отражает скорость разработки. Чем медленнее мы будем выкатывать гипотезы – тем с большей вероятностью нас обгонят конкуренты или мы просто потратим все деньги на команду и не найдём product…
Про детализацию информации
Мечтаю о таком приложении, которое позволит изменять детализацию в любом потоке информации.
– Вернулся в интернет после месячного ретрита? Оно расскажет за 5 минут только о главных событиях (вы же не хотите читать весь твиттер за месяц и листать все новости?)
– Читаешь лонгрид на больную тему? Ставишь максимум детализации. Просто интересены шаги и выводы или мало времени? Двигаешь ползунок влево – в тексте пропадает вся литература и авторский стиль и остаются только факты.
– Интересно, как дела сейчас в компании? Видишь дашборд только с основными цифрами. За что-то зацепился глаз? Провалились в конкретную команду или проект, повысили детализацию и смотрим цифры, результаты и какие возникали проблемы.
Но пока управлять потоками информации могут только люди и важно понимать, кому и какой уровень детализации необходим. Внутри команды люди хотят понимать, чем они будут заниматься на этой неделе, где взять необходимые доступы и найти прототипы экранов. Соседняя команда хочет видеть, как продвигаются задачи, которые они просили делать. Руководители – понимать, приближаемся ли мы к поставленным целям. А если долго не приближаемся – «провалиться» в детали, найти, что пошло не так и помочь исправить это.
В общем, одна и та же информация должна выглядеть по-разному для разных людей и их контекста. Одних не нужно перегружать лишней информаций, а другим наоборот, нужно дать все мельчайшие детали.
Мечтаю о таком приложении, которое позволит изменять детализацию в любом потоке информации.
– Вернулся в интернет после месячного ретрита? Оно расскажет за 5 минут только о главных событиях (вы же не хотите читать весь твиттер за месяц и листать все новости?)
– Читаешь лонгрид на больную тему? Ставишь максимум детализации. Просто интересены шаги и выводы или мало времени? Двигаешь ползунок влево – в тексте пропадает вся литература и авторский стиль и остаются только факты.
– Интересно, как дела сейчас в компании? Видишь дашборд только с основными цифрами. За что-то зацепился глаз? Провалились в конкретную команду или проект, повысили детализацию и смотрим цифры, результаты и какие возникали проблемы.
Но пока управлять потоками информации могут только люди и важно понимать, кому и какой уровень детализации необходим. Внутри команды люди хотят понимать, чем они будут заниматься на этой неделе, где взять необходимые доступы и найти прототипы экранов. Соседняя команда хочет видеть, как продвигаются задачи, которые они просили делать. Руководители – понимать, приближаемся ли мы к поставленным целям. А если долго не приближаемся – «провалиться» в детали, найти, что пошло не так и помочь исправить это.
В общем, одна и та же информация должна выглядеть по-разному для разных людей и их контекста. Одних не нужно перегружать лишней информаций, а другим наоборот, нужно дать все мельчайшие детали.
Как фокусироваться на главном?
Чем больше делаю задач, тем больше их становится, а времени они занимают всё больше. И тем чаще замечаю, что закон Паркинсона (что работа занимает всё отведённое на неё время) – правда.
Именно когда это понимаешь, осознаёшь важность сроков, особенно для себя самого. Задачу можно сделать по разному в зависимости от ресурсов (временных, интеллектуальных, денежных), которыми мы обладаем. В этом основная идея appetites из методологии Shape Up от Basecamp – мы фиксируем время, которое хотим потратить на фичу, а не скоуп этой фичи. Если успеваем – она будет доведена до идеала, если нет – пойдёт в продакшен в минимальном и простейшем виде.
Думаю, именно чтобы больше фокусироваться только на главном стартап Bolt перешел на четырехдневную рабочую неделю. Теперь у сотрудников времени стало меньше, а результаты как-то нужно успевать показывать, а значит не будет времени на ненужные мелочи.
В общем, хотите фокусироваться на главном? Ограничивайте своё время на выполнение задач.
Чем больше делаю задач, тем больше их становится, а времени они занимают всё больше. И тем чаще замечаю, что закон Паркинсона (что работа занимает всё отведённое на неё время) – правда.
Именно когда это понимаешь, осознаёшь важность сроков, особенно для себя самого. Задачу можно сделать по разному в зависимости от ресурсов (временных, интеллектуальных, денежных), которыми мы обладаем. В этом основная идея appetites из методологии Shape Up от Basecamp – мы фиксируем время, которое хотим потратить на фичу, а не скоуп этой фичи. Если успеваем – она будет доведена до идеала, если нет – пойдёт в продакшен в минимальном и простейшем виде.
Думаю, именно чтобы больше фокусироваться только на главном стартап Bolt перешел на четырехдневную рабочую неделю. Теперь у сотрудников времени стало меньше, а результаты как-то нужно успевать показывать, а значит не будет времени на ненужные мелочи.
В общем, хотите фокусироваться на главном? Ограничивайте своё время на выполнение задач.
Маркер фигни
Обнаружил максимально простой маркер «а не фигню ли я делаю?» (или кто-то другой). Если не получается ответить в одном предложении на вопросы что и зачем я делаю – то варианта 2: либо это фигня, либо не до конца разобрался (и через некоторое время нужно вернуться к исходному вопросу). Причем чем больше условий, уточнений и дополнений, вроде «а ещё...» в ответе – тем хуже.
Этот же вопрос работает и для продуктов, и для команд (и даже для кода!). Например:
– Большинство успешных и быстрорастущих стартапов в каждый момент времени сфокусированы на решении одной конкретной проблемы
– Команда работает максимально эффективно, если у неё есть общая цель, а не набор несвязных между собой задач для каждого исполнителя.
– Если посмотрев на код нельзя в одном предложении ответить, что и зачем он делает – это плохой код.
В общем, хотите понять, а не фигнеё ли заняты люди вокруг? Просто спросите
Обнаружил максимально простой маркер «а не фигню ли я делаю?» (или кто-то другой). Если не получается ответить в одном предложении на вопросы что и зачем я делаю – то варианта 2: либо это фигня, либо не до конца разобрался (и через некоторое время нужно вернуться к исходному вопросу). Причем чем больше условий, уточнений и дополнений, вроде «а ещё...» в ответе – тем хуже.
Этот же вопрос работает и для продуктов, и для команд (и даже для кода!). Например:
– Большинство успешных и быстрорастущих стартапов в каждый момент времени сфокусированы на решении одной конкретной проблемы
– Команда работает максимально эффективно, если у неё есть общая цель, а не набор несвязных между собой задач для каждого исполнителя.
– Если посмотрев на код нельзя в одном предложении ответить, что и зачем он делает – это плохой код.
В общем, хотите понять, а не фигнеё ли заняты люди вокруг? Просто спросите
Про отвлечения #toolset
Из-за мессенджеров и бесконечного потока информации мне кажется только мааааленький процент людей умеет долго и сфокусировано работать. И да, я считаю что это именно навык, а не набор обстоятельств – каждый управляет своим временем, как хочет. Так что если вы считаете «ну у нас принято сразу в телеге отвечать» вы знаете, какой навык можете попробовать развить 😉
Так вот, мессенджеры разрываются, в почту валятся десятки писем. В момент, когда они приходят всегда кажется, что это ОЧЕНЬ ВАЖНО и нужно отвлечься прямо сейчас. Как лечится – понятно. Отключаем уведомления. Сначала страдаем от ломки и FOMO, а потом ощущаем увеличение продуктивности, улучшение ментального состояния и осознание того, что многие задачи решаются без вашего участия. И то, что могло бы показаться срочной важной задачей заканчивается сообщением «не актуально, разобрались)»
Потом наступает новое состояние, когда любые 3 минуты свободного времени на автомате хочется открыть телеграм. А там ещё и новые интересные посты в каналах появились и вот, как нам кажется, мы заняты чтением полезного контента (но планировали мы заняться чем-то другим).
Рецепт моей борьбы:
1. Выбираем, как часто хотим читать мессенджеры
Например, раз в 15 или 25 минут и убираем с экрана любые напоминания о непрочитанных сообщениях.
2. Регистрируемся в inoreader
Тут мы будем хранить все наши подписки. Можно использовать аналогичные сервисы, типа feedly.
3. Добавляем все телеграм-каналы туда
В inoreader подписка на телеграм-каналы – платная фича, так что проще добавить все каналы через rsshub. Например, ссылка на мой канал: http://rsshub.app/telegram/channel/sn_hack.
4. Отписываемся от всех в телеграме!
И он снова становится просто мессенджером.
5. Планируем потребление контента
Чтобы не занимать любое свободное время разбором контента – запланируем его и явно добавим в календарь. Например, 2-3 раза в неделю по 30-45 минут вполне достаточно.
Бонус шаг: ставим Reeder. Это просто красивый интерфейс для чтения inoreader с возможностью добавлять статьи в read it later и чтением в оффлайне.
P.S. У такого подхода есть один неочевидный минус. Думаю многих авторов мотивирует количество подписчиков, просмотров постов и шейров/реакций, а отказ от официальных клиентов телеграма уменьшит эти числа. И что с этим делать я пока не придумал:)
Из-за мессенджеров и бесконечного потока информации мне кажется только мааааленький процент людей умеет долго и сфокусировано работать. И да, я считаю что это именно навык, а не набор обстоятельств – каждый управляет своим временем, как хочет. Так что если вы считаете «ну у нас принято сразу в телеге отвечать» вы знаете, какой навык можете попробовать развить 😉
Так вот, мессенджеры разрываются, в почту валятся десятки писем. В момент, когда они приходят всегда кажется, что это ОЧЕНЬ ВАЖНО и нужно отвлечься прямо сейчас. Как лечится – понятно. Отключаем уведомления. Сначала страдаем от ломки и FOMO, а потом ощущаем увеличение продуктивности, улучшение ментального состояния и осознание того, что многие задачи решаются без вашего участия. И то, что могло бы показаться срочной важной задачей заканчивается сообщением «не актуально, разобрались)»
Потом наступает новое состояние, когда любые 3 минуты свободного времени на автомате хочется открыть телеграм. А там ещё и новые интересные посты в каналах появились и вот, как нам кажется, мы заняты чтением полезного контента (но планировали мы заняться чем-то другим).
Рецепт моей борьбы:
1. Выбираем, как часто хотим читать мессенджеры
Например, раз в 15 или 25 минут и убираем с экрана любые напоминания о непрочитанных сообщениях.
2. Регистрируемся в inoreader
Тут мы будем хранить все наши подписки. Можно использовать аналогичные сервисы, типа feedly.
3. Добавляем все телеграм-каналы туда
В inoreader подписка на телеграм-каналы – платная фича, так что проще добавить все каналы через rsshub. Например, ссылка на мой канал: http://rsshub.app/telegram/channel/sn_hack.
4. Отписываемся от всех в телеграме!
И он снова становится просто мессенджером.
5. Планируем потребление контента
Чтобы не занимать любое свободное время разбором контента – запланируем его и явно добавим в календарь. Например, 2-3 раза в неделю по 30-45 минут вполне достаточно.
Бонус шаг: ставим Reeder. Это просто красивый интерфейс для чтения inoreader с возможностью добавлять статьи в read it later и чтением в оффлайне.
P.S. У такого подхода есть один неочевидный минус. Думаю многих авторов мотивирует количество подписчиков, просмотров постов и шейров/реакций, а отказ от официальных клиентов телеграма уменьшит эти числа. И что с этим делать я пока не придумал:)
Inoreader
Inoreader – Build your own newsfeed
With Inoreader, content comes to you the minute it's available. Follow websites, social media feeds, podcasts, blogs, and newsletters. Enjoy what's important to you, all in one place.
Ностальгия по качеству
За последние 2–3 недели я зарегистрировался в паре десятков сервисов, которые заявляют себя как «Создай иконку / интерфейс / веб-сайт / мобильное приложение / космический корабль по текстовому описанию». Половина из них даже не работают — собирают почты в waitlist. Думаю, что 80% из них закончат тем, что сделают еле работающую простейшую демку и пойдут искать инвесторов. Возможно, кто-то и найдёт, но, думаю, через год будет существовать максимум 3% этих продуктов. И вот они-то начнут делать классный, качественный продукт...
Ха-ха, конечно нет! Мы же не в 2010-м: они будут собирать всё криво, на коленке и с кучей багов. Первым делом будут работать над онбордингом, обещая внутри невероятные технологии, которые изменят ваш быт навсегда. Но обещать — не значит жениться. В реальности продукт будет способен делать процентов 10–20 от того, что будет обещано на лендинге и в онбординге. Странно, ведь в testimonials лучшие люди планеты пишут, как сильно изменилась их жизнь...
Может, мы просто попали в неудачный A/B-тест? Ладно, просто закроем приложение... До первого пуш-уведомления — ведь ретеншен сам себя не поднимет. Да, facebook может доказывать, что иногда лучше меньше пушей, чем больше. Но у pre-seed-стартапов нет столько времени и денег, чтобы ждать результаты в течение года, да и параллельные A/B-тесты проводить сложнее. Стат-значимый результат? В продакшен на 100%. В приложении баги, а на почте пачка предложений от пользователей? Оставим на потом, ведь продакт-менеджеров не повышают за внимание к деталям и отсутствие багов, если это не приводит к росту метрик. Следующая гипотеза — письмо «It's sad to see you're leaving» с предложением скидки после отписки от сервиса.
К чему это я? Понятно, что рынок решает, и такой подход максимально эффективен для бизнеса и фаундеров. Но грустно, что остаётся всё меньше и меньше продуктов и компаний, которые не занимаются бесконечным гроуз-хакингом, а делают классные до мелочей продукты. Знаете такие? Поделитесь в комментариях — хочется вернуть свою веру в IT 🙂
За последние 2–3 недели я зарегистрировался в паре десятков сервисов, которые заявляют себя как «Создай иконку / интерфейс / веб-сайт / мобильное приложение / космический корабль по текстовому описанию». Половина из них даже не работают — собирают почты в waitlist. Думаю, что 80% из них закончат тем, что сделают еле работающую простейшую демку и пойдут искать инвесторов. Возможно, кто-то и найдёт, но, думаю, через год будет существовать максимум 3% этих продуктов. И вот они-то начнут делать классный, качественный продукт...
Ха-ха, конечно нет! Мы же не в 2010-м: они будут собирать всё криво, на коленке и с кучей багов. Первым делом будут работать над онбордингом, обещая внутри невероятные технологии, которые изменят ваш быт навсегда. Но обещать — не значит жениться. В реальности продукт будет способен делать процентов 10–20 от того, что будет обещано на лендинге и в онбординге. Странно, ведь в testimonials лучшие люди планеты пишут, как сильно изменилась их жизнь...
Может, мы просто попали в неудачный A/B-тест? Ладно, просто закроем приложение... До первого пуш-уведомления — ведь ретеншен сам себя не поднимет. Да, facebook может доказывать, что иногда лучше меньше пушей, чем больше. Но у pre-seed-стартапов нет столько времени и денег, чтобы ждать результаты в течение года, да и параллельные A/B-тесты проводить сложнее. Стат-значимый результат? В продакшен на 100%. В приложении баги, а на почте пачка предложений от пользователей? Оставим на потом, ведь продакт-менеджеров не повышают за внимание к деталям и отсутствие багов, если это не приводит к росту метрик. Следующая гипотеза — письмо «It's sad to see you're leaving» с предложением скидки после отписки от сервиса.
К чему это я? Понятно, что рынок решает, и такой подход максимально эффективен для бизнеса и фаундеров. Но грустно, что остаётся всё меньше и меньше продуктов и компаний, которые не занимаются бесконечным гроуз-хакингом, а делают классные до мелочей продукты. Знаете такие? Поделитесь в комментариях — хочется вернуть свою веру в IT 🙂
Почему ChatGPT меня не заменит
Когда я начинал заниматься вебом, я писал код в блокноте, копи-пастил хаки, чтобы полупрозрачность работала во всех браузерах, включая IE6, а единственным вариантом отладки JS-кода был
Постепенно веб обрастал тулингом и фреймворками и сейчас какой-нибудь next.js + vercel из коробки предоставит все best-practices и будет работать быстро и качественно – он за вас всё оптимизирует, порежет, сожмёт, раскатит. Достаточно просто следовать гайдам и ничего не сломать. Но даже используя next.js нужны опытные разработчики, просто они теперь решают другие проблемы, которые ещё не решены фреймворком.
Вслед за тулингом и фреймворками появились сотни курсов на которых учат использовать эти самые тулзы и фреймворки и обещают 300к/cек после окончания. Большинство выпускнинов ограничиваются поверхностными скилами в том, как использовать конкретные инструменты, но ценными разработчиками становятся те, кто закапывается в детали и понимает, как же всё работает под капотом. А работает всё почти так же, как и 15 лет назад.
Получается, что самые ценные знания – те, которые не меняются годами. За 15 лет не произошло ни одной "революции" ни в бекенде, ни во фронтенде, ни в базах данных. Всё, что происходило – небольшие планомерные дополнения и улучшения. Те, кто понимает базовые принципы разработки легко переходят с одного языка на другой. Те, кто понимает как работает браузер и JS легко переключаются с react на vue или svelte. В других областях знаний (дизайне, продажах, менеджменте) всё аналогично – фундаментальные знания и опыт намного важнее знания конкретных инструментов.
Так вот, теперь появляется новая волна тулинга – ChatGPT и прочие AI-ассистенты. Многие задумываются, а не заменят ли их эти ассистенты. И ответ для меня очевиден: нет, пока вы инвестируете своё время и силы в фундаментальные знания, которые не меняются годами. Именно в паре с этими знаниями ChatGPT станет ассистентом, а не заменой.
Когда я начинал заниматься вебом, я писал код в блокноте, копи-пастил хаки, чтобы полупрозрачность работала во всех браузерах, включая IE6, а единственным вариантом отладки JS-кода был
window.alert (потому что DevTools тогда ещё не было и console.log писать было некуда). Меня всегда интересовали best-practices написания кода и способы ускорить то, что и так работает. Для этого приходилось закапываться в детали и постоянно следить за изменениями – в чем разница между http/2 и http 1.1? Как работает браузер и рендерит сайты? Что под капотом использует jquery/angular/react? Как сделать свой CI?Постепенно веб обрастал тулингом и фреймворками и сейчас какой-нибудь next.js + vercel из коробки предоставит все best-practices и будет работать быстро и качественно – он за вас всё оптимизирует, порежет, сожмёт, раскатит. Достаточно просто следовать гайдам и ничего не сломать. Но даже используя next.js нужны опытные разработчики, просто они теперь решают другие проблемы, которые ещё не решены фреймворком.
Вслед за тулингом и фреймворками появились сотни курсов на которых учат использовать эти самые тулзы и фреймворки и обещают 300к/cек после окончания. Большинство выпускнинов ограничиваются поверхностными скилами в том, как использовать конкретные инструменты, но ценными разработчиками становятся те, кто закапывается в детали и понимает, как же всё работает под капотом. А работает всё почти так же, как и 15 лет назад.
Получается, что самые ценные знания – те, которые не меняются годами. За 15 лет не произошло ни одной "революции" ни в бекенде, ни во фронтенде, ни в базах данных. Всё, что происходило – небольшие планомерные дополнения и улучшения. Те, кто понимает базовые принципы разработки легко переходят с одного языка на другой. Те, кто понимает как работает браузер и JS легко переключаются с react на vue или svelte. В других областях знаний (дизайне, продажах, менеджменте) всё аналогично – фундаментальные знания и опыт намного важнее знания конкретных инструментов.
Так вот, теперь появляется новая волна тулинга – ChatGPT и прочие AI-ассистенты. Многие задумываются, а не заменят ли их эти ассистенты. И ответ для меня очевиден: нет, пока вы инвестируете своё время и силы в фундаментальные знания, которые не меняются годами. Именно в паре с этими знаниями ChatGPT станет ассистентом, а не заменой.
Cleanshot
sgawzkumv9ma1
Screenshot uploaded to CleanShot Cloud