А что мешает платить за электричество через сайт мособлэнергосбыта? Оплачиваю так уже почти год (до этого платил через alfa-click). К оплате спокойно принимается любая карта. За газ плачу через Сбербанк-онлайн, а на сайте мособлгаза контролирую пришел платеж или нет.
Хороший пост. Однако
1. не могу понять, почему нельзя руководителю быть в курилке подчиненных. Постоянно, да. А набегами — вполне возможно.
2. гендиректору всё-таки не обязательно пройти все круги ада. Нужно подняться по лестнице соответствующего профиля компании (т.е. если компания занимается разработкой ПО то программист, финансы то хотя бы бухгалтерия) и иметь опыт работы с другими областями деятельности компании (бухгалтерия, логистика и т.п.)
_Вот об этом я и говорю — планирование будет все равно лежать на разработчике, так зачем тогда менеджер?!
Давайте не будем путать оценку сроков и зависимости задач с планированием всех задач. Разработчик нужен менеджеру при планировании только лишь для исключения ситуации «этот срок нереальный» или «это нельзя сделать, не сделав это»
_Если уж исполнитель задачи, единственный, кто владеет знаниями о ней и компетентен в этой области не может оценить время, тогда его никто не сможет оценить. И опять же вопрос — зачем тогда менеджер?
Исполнитель оценивает чистое время разработки указанной задачи, и не учитывает время на тестирование (в том числе свое и чужое), не учитывает время развертывания и временные окна на развертывание, не учитывает согласование с другими задачами. В комплексе это может оценить ТехДир или ТимЛид(реже)
_Если я захочу, я смогу наплести чего угодно менеджеру и он поверит, потому, что я эксперт в вопросе, а он — нет. Опять же вопрос — зачем тогда менеджер?
Конечно можете, по первости то. Но обратная связь для этого и существует что бы потом сделать правильные выводы. Отпустить вас по вашим личным делам или нет, премировать вас или нет, оставить вас или сократить.
_Я хочу сказать, что в подавляющем большинстве менеджер не нужен.
Увы но это заблуждение. Когда я был программистом а затем ведущим программистом я тоже так рассуждал. Перейдя в техдиры, я понял что это мнение ошибочно. Если программистов больше трех то команде уже нужен менеджер. Неважно, техдир он или тимлид, но он должен выполнять функции управления и принятия решений. Он двухстронний фильтр как для програмистов от клиентов так и для клиентов от программистов. Он предотвращает расколы на почве «священных войн» среди программистов, он не дает команде развалится, он в курсе проблем каждого члена команды и знает подход к каждому. Программистоы бывает заносит, и они в угоду «правильного кода» готовы поставит под угрозу весь бизнес, Кто за это отвечает? Менеджер. Клиенты хотят здесь и сейчас. Кто им доступно объяснит что реально а что нет? Причем зачастую это надо объяснять на уровне первого класа церковно-приходской школы. Программист? Он горд собой и своими знаниями он хочет творить а не сюсюкаться.
У меня было несколько примеров когда, я давал полную свободу принятия решений на откуп ведущему разработчику, который общался напрямую с клинтом (ПМ со стороны клиента). В обоих случах сроки были сорваны на несколько месяцев. Оба раза по вине программистов, причем они свою вину упорно не признавали. А когда были прижаты фактами — сказали что из за всей этой менеджерской ерунды и сюсюканья с клиентами у них не было времени на разработку. Но по факту они даже сроки клиенту называли нереальные. И развертывание проекта из оцененных 5 часов превратилось в 12.
P.S. Я 5 лет был разработчиком, потом 10 лет менеджером (техдир, руководитель департамента)
Планирование вы можете осуществлять имея постоянную обратную связь с разработчиками. Грубое планирование можно осуществлять самому если до этого был бэкграунд программиста. Если бекграунда нет то начинать планирование надо вместе с разработчиками, и постепеннно набирать опыт. При этом надо понимать что программисты (в подавляющем большинстве своем) — НЕ УМЕЮТ правильно оценивать задачи. Поэтому по началу дробим задачи на подзадачи с максимальным сроком день (ответ программиста — " я за пол-дня, пару часов это сделаю"). а дальше понимая индивидуальную производительность каждого разработчика или общей команды (если у вас формируются зачатки SCRUM) начинаете планировать сами (но непременено согласовывая срок с программистами).
Многие начинающие менеджеры боятся такого подхода, думая что срок, названый программистами, завышен. Это не страшно что завышен (хуже когда он занижен, поверьте), тут вступает в действие второй пункт — КОНТРОЛЬ. Вы должны быть постоянно на связи с програмимистами, видеть чем они занимаются. Они должны понимать что если вдруг у них что то пойдет не так — вы на ИХ стороне. Ошиблись в сроках? Разобрались почему (недостаток компетенции, неполная информация от вас, и т.п.) — у вас должен быть запас по срокам (+1 день например от внутрененего срока, ко внешнему сроку) который вы отдадите (конечно с боем :)) им, но ситуация будет разрулена. Но не пользуйтесь этим приёмом постоянно, повышайте качество оценки программиста вместе со своим.
не не. ЖРАТЬ-СРАТЬ-РЖАТЬ, это понятно. а кроме потреблятства (поверьте это быстро наскучит)? рисовать например или столы делать (это я вообще с потолка взял). У меня есть примеры перед глазами, когда люди уходили из IT вообще в другие сферы и поднимались там куда выше, хотя до этого были программистами-рабочими лошадками.
Мне в этом плане легче, программирование & IT для меня стало хобби и радостью жизни. Хотя я иногда задаю себе вопрос, «А вот если не программирование & IT то тогда кем пойти?»
Ну вот, если есть занятие и есть идеи, которые хочется реализовать — ищите партнера c деньгами или инвестора. Сферу представляете себе, организовывать умеете. Что не хватает? Времени? Вам выше написали много советов как разгрести время, мне пока добавить нечего. начните пока параллельно, потом если начнет складываться — уволитесь.
Блин, вопрос «Чем я буду заниматься когда мне станет 34, 40,45?» занимает меня с 30 лет. и вот уже тоже 35 лет, послужной список победнее Вашего, но я нашел для себя ответ — свой стартап и двигаюсь в этом направлении. Но насколько он окажется верен — не пока не знаю :) Перед глазами партнер 50+ запускающий 4-тый стартап :)
В стартапе я взял на себя весь production проекта, потом подтянем исполнителей. Это хорошо освежило память и к слову, в стартапе зачастую быстрее так проще и быстрее. Делегировать сделать то что сам еще толком не понимаешь как будет работать — сложно.
Как то так, а по текущей ситуции — не бойтесь делегирования. Да, в какой то момент есть ощущение своей ненужности, но это потом пройдет.
Нужно находить радость в работе. Когда на работу как на каторгу, то это хуже нет. Подумайте чем бы вы хотели заниматься в удовольствие, и посмотритете можно ли этим заняться используя полученный опыт. Это не так сложно как кажется. Сложнее на это решиться.
К слову это нормальная практика: поставив задачу и делегировав полномочия ты требуешь (ИМЕННО ТРЕБУЕШЬ) держать тебя во всей переписке в копии. Основной аргумент, причины копии, который понимают все — если задача будет просрана, то виноваты будете вы, т.к. вовремя меня не информировали.
Да, ты начинаешь ловить более 200+ писем в день, но все это копии и зачастую, НЕ ОТКРЫВАЯ письмо, по первому предложению (тут еще конечно нужна дрессировка своей команды, что в одном письме не может быть обсуждения нескольких вопросов) понятно как идет процес.
Да они разбросаны по разным странам. НО, если вы начнете перебирать по странам то будете (не)приятно удивлены что там частые пересечения :) и кол-во приложений будет примерно такое же :)
Тоже как то парсил Google Play для американского рынка, Набросал на C# консольное приложение страницу парсил используя HtmlAgilityPack (XPATH), правда делал не поиск по AAA AAB и т.п, а сначала выбирал все с главной из категорий, потом со страницы приложения переход на все страницы компании, потом на все related и так по кругу. Эффективная выборка шла не больше 8 часов, (на Ноутбуке с 1,6GHz), дальше пошли повторения которые отсекались и особого прироста не было, поэтому остановил. итог: ~32К
Ну скажем так, vk.com тогда был с другой аудиторией (объем) да и отношение к пользователям у vk.com не такое трепетное как у FB (сколько изменений соглашения и правил)
И да. Стал начинать «отличаться». Однако старт был с копией.
Ну тут сложно как то спорить. Тогда можно попробовать сравнить iPhone с калькулятором или с читалкой. На нем тоже можно считать и складывать, да и тексты читать на нем можно.
Я бы вообще все это безобразие называл телефонами. :)
Ну вообще есть статья в Wikipedia — Смартфон. Но суть не в этом. Просто сама Apple позиционирует iPhone как телефон. Хотя не спорю, по функционалу он приближается к смартфону.
1. не могу понять, почему нельзя руководителю быть в курилке подчиненных. Постоянно, да. А набегами — вполне возможно.
2. гендиректору всё-таки не обязательно пройти все круги ада. Нужно подняться по лестнице соответствующего профиля компании (т.е. если компания занимается разработкой ПО то программист, финансы то хотя бы бухгалтерия) и иметь опыт работы с другими областями деятельности компании (бухгалтерия, логистика и т.п.)
Давайте не будем путать оценку сроков и зависимости задач с планированием всех задач. Разработчик нужен менеджеру при планировании только лишь для исключения ситуации «этот срок нереальный» или «это нельзя сделать, не сделав это»
_Если уж исполнитель задачи, единственный, кто владеет знаниями о ней и компетентен в этой области не может оценить время, тогда его никто не сможет оценить. И опять же вопрос — зачем тогда менеджер?
Исполнитель оценивает чистое время разработки указанной задачи, и не учитывает время на тестирование (в том числе свое и чужое), не учитывает время развертывания и временные окна на развертывание, не учитывает согласование с другими задачами. В комплексе это может оценить ТехДир или ТимЛид(реже)
_Если я захочу, я смогу наплести чего угодно менеджеру и он поверит, потому, что я эксперт в вопросе, а он — нет. Опять же вопрос — зачем тогда менеджер?
Конечно можете, по первости то. Но обратная связь для этого и существует что бы потом сделать правильные выводы. Отпустить вас по вашим личным делам или нет, премировать вас или нет, оставить вас или сократить.
_Я хочу сказать, что в подавляющем большинстве менеджер не нужен.
Увы но это заблуждение. Когда я был программистом а затем ведущим программистом я тоже так рассуждал. Перейдя в техдиры, я понял что это мнение ошибочно. Если программистов больше трех то команде уже нужен менеджер. Неважно, техдир он или тимлид, но он должен выполнять функции управления и принятия решений. Он двухстронний фильтр как для програмистов от клиентов так и для клиентов от программистов. Он предотвращает расколы на почве «священных войн» среди программистов, он не дает команде развалится, он в курсе проблем каждого члена команды и знает подход к каждому. Программистоы бывает заносит, и они в угоду «правильного кода» готовы поставит под угрозу весь бизнес, Кто за это отвечает? Менеджер. Клиенты хотят здесь и сейчас. Кто им доступно объяснит что реально а что нет? Причем зачастую это надо объяснять на уровне первого класа церковно-приходской школы. Программист? Он горд собой и своими знаниями он хочет творить а не сюсюкаться.
У меня было несколько примеров когда, я давал полную свободу принятия решений на откуп ведущему разработчику, который общался напрямую с клинтом (ПМ со стороны клиента). В обоих случах сроки были сорваны на несколько месяцев. Оба раза по вине программистов, причем они свою вину упорно не признавали. А когда были прижаты фактами — сказали что из за всей этой менеджерской ерунды и сюсюканья с клиентами у них не было времени на разработку. Но по факту они даже сроки клиенту называли нереальные. И развертывание проекта из оцененных 5 часов превратилось в 12.
P.S. Я 5 лет был разработчиком, потом 10 лет менеджером (техдир, руководитель департамента)
Многие начинающие менеджеры боятся такого подхода, думая что срок, названый программистами, завышен. Это не страшно что завышен (хуже когда он занижен, поверьте), тут вступает в действие второй пункт — КОНТРОЛЬ. Вы должны быть постоянно на связи с програмимистами, видеть чем они занимаются. Они должны понимать что если вдруг у них что то пойдет не так — вы на ИХ стороне. Ошиблись в сроках? Разобрались почему (недостаток компетенции, неполная информация от вас, и т.п.) — у вас должен быть запас по срокам (+1 день например от внутрененего срока, ко внешнему сроку) который вы отдадите (конечно с боем :)) им, но ситуация будет разрулена. Но не пользуйтесь этим приёмом постоянно, повышайте качество оценки программиста вместе со своим.
Мне в этом плане легче, программирование & IT для меня стало хобби и радостью жизни. Хотя я иногда задаю себе вопрос, «А вот если не программирование & IT то тогда кем пойти?»
Ну вот, если есть занятие и есть идеи, которые хочется реализовать — ищите партнера c деньгами или инвестора. Сферу представляете себе, организовывать умеете. Что не хватает? Времени? Вам выше написали много советов как разгрести время, мне пока добавить нечего. начните пока параллельно, потом если начнет складываться — уволитесь.
В стартапе я взял на себя весь production проекта, потом подтянем исполнителей. Это хорошо освежило память и к слову, в стартапе зачастую быстрее так проще и быстрее. Делегировать сделать то что сам еще толком не понимаешь как будет работать — сложно.
Как то так, а по текущей ситуции — не бойтесь делегирования. Да, в какой то момент есть ощущение своей ненужности, но это потом пройдет.
Да, ты начинаешь ловить более 200+ писем в день, но все это копии и зачастую, НЕ ОТКРЫВАЯ письмо, по первому предложению (тут еще конечно нужна дрессировка своей команды, что в одном письме не может быть обсуждения нескольких вопросов) понятно как идет процес.
И да. Стал начинать «отличаться». Однако старт был с копией.
Я бы вообще все это безобразие называл телефонами. :)