lahomie93

Новичкам обычно выбирать не приходится.

В первый месяц мне дают задачу и просят дать точную оценку. А я не могу ее дать, потому что:
1. Я не понимаю еще работу действующих систем;
2. Я не понимаю какое количество систем нужно будет доработать, чтобы решить задачу;
3. Я не знаю насколько документация точно соответствует и нужен ли делать реверс-инжиниринг кода

И таких "не понимаю/не знаю" у меня первые 3-6 месяцев работы очень много

Если совсем нет инфы, то говори "мне нужно столько-то времени, чтобы дать примерную оценку, напишу позже".

Если счёт на часы - говори "пару дней".
Если счёт на дни - говори "неделю или две".
Если счёт на месяцы - говори "через год/к осени/итд"
Ибо чем больше срок - тем больше неизвестность. Чем больше неизвестность - тем выше вероятность, что срок будет расти.
Если задача много времени требует - лучше разделить на несколько более достижимых целей и давать оценку следующей, после выполнения предыдущей.

К примеру "Сколько времени займёт сделать вот такой продукт?" (на первый взгляд - дофига) - отвечаешь "Proof of concept с вот такими минимальными фичами сделаем через столько-то"

чтоб работать в лучших компаниях, ты должен сам быть лучшим, в конкурентных условиях когда все динамично развивается - это означает постоянное развитие, обучение, как правило ценой потери взаимоотоношений, семьи, развлечений. Это единственный путь наверх.
Но можно быть "средним", тогда ничего этого не нужно. Само собой подавляющее большинство компаний посредственные, так же как и кадры которые там работают и это нормально. Не нормально это когда в посредственной компании с кадров спрашивают будто ты в гугле работаешь))))

Очень много интересного почерпнул в этом треде.
Казалось бы, автор задаёт один простой вопрос "почему люди не отмечают затраченное время?". И столько пустой болтовни, ненужных советов, не относящихся к этому вопросу. Размусоливаний каких-то ситуаций, которые у них на работе, но, опять же, абсолютно не относящихся к данному вопросу. Или переход к другой теме, например, много было про оценку задач, да, это интересные всё темы, но это опять же не относится к теме данного поста.
Автор меня приятно удивил, пытаясь вначале отвечать всем и по существу, но уже устал к концу, хотя верные ответы находятся не на самых залайканных ответах.
Одно время я поработал в компании, где после каждой задачи надо было писать отчёт, прикладывая листинг кода! так как реально вообще другой отдел занимался сдачей отчётности (по списанным часам из таких отчётов выставлялся счёт заказчикам) и они даже не в курсе были, чем занимаются программисты. Большего маразма я в жизни не встречал. И когда я стал работать в других компаниях, где надо просто списать затраченное время, я понял, что это прям намного проще и понимаю, зачем это надо менеджменту.
Но тут встретил людей, которые этого не понимают. То есть, в текущей конторе не было такого, что надо списывать время. Многие (из старичков) откровенно саботировали этот процесс, сопротивление просто громадное, одно из лидирующих мнений было, примерно, следующее: "я раньше не списывал время и сейчас не собираюсь, потому что мне это не надо". Понятное дело, что в такой ситуации весь менеджмент и планирование в полной жопе. Ну, мне понятно. И тут возникает главная загвоздка и ответ на этот тред. Вам необходимо, во-первых, правильно объяснить, зачем это надо. Во-вторых, сделать учёт времени неотъемлемой частью процесса.
Аргументов по первому пункту тут уже приводилось много и варианты для конкретного человека могут быть довольно специфичные. Что если сотрудник будет просто списывать время, то уже будет видна его загрузка и можно меньше задач ставить в спринт. Или другой пример, один сотрудник сидит на каком-то проекте и ни холодно ни жарко другим людям списывает он время или нет, но появляется какая-то задача, надо ему сделать апи для другого сотрудника. И эта задача блокирующая, но он её не делает. Отговариваясь на митингах, что занимался другим. "Дружок, я не вижу, чем ты занимаешься, если нет списанного времени, я могу считать, что ты ничем не занимаешься, но при этом блокирующая задача перенесена в другой спринт" - разбор полётов и обоснование для списания времени.
Есть такой тип людей, где-то тут тоже мелькало "я забиваю на списанное время и в конце недели просто рисую цифры с потолка, чтобы отстали". Такое тоже присутствует. Это низкая культура и низкая дисциплина. И с этим тоже можно работать (это относится ко второму пункту). Так же в этом треде предлогались решения, кто-то сказал, что тимлид сказал списывать время в конце дня, как закончил работать. Ну, запретите на программном уровне списывать время за предыдущие дни. Справедливости ради стоит отметить, что иногда вечером не всегда успеваешь это делать, то есть, можно сделать так, что списывать время можно предыдущий день можно до дейли митинга (до 10 утра, к примеру). Если это не происходит, то в присутствии всей команды уточнять, чем человек занимался вчера и напирать на то, что вместо того, чтобы быстренько занести своё время теперь этот человек крадёт время всей команды.
Резюмируя, первое, надо доходчиво объяснить, зачем это нужно работнику (не вам, а ему), второе, необходимо сделать списание времени частью рабочего процесса

В любом контракте должны быть прописаны действия при не соблюдении условий любой из сторон. Если такого нет то никто никому на самом деле не должен ничего кроме как закончить работу и оплатить ее

Пока что пришел к тому, что самое эффективное, хотя и не 100% решение - это настроить трекер таким образом, чтобы при переводе в определенные статусы трекер требовал отметить время.

Также нужно на стэндапах/митингах/планерках доносить важность этого, если это действительно важно, и напоминать забывающим перед всей командой.

p.s. был один неизлечимый случай, и этого человека перевел на почасовую оплату (правда были ещё причины для этого). Проблем с трекингом времени теперь нет.

У нас компания достаточно маленькая, но что сделал мой начальник: Он написал простой сайт, куда мы записываем имя компании и потраченное время + проведённую работу. Выполнил задание - добавил на сайт и клиент получает счёт на эти часы. Оплату мы берём за единицы по 15 минут, то есть 3 часа работы это 12 единиц по определённому прайсу, в данном приложении вписываем собственно кол-во единиц.
Ну и в принципе всё, тут люди говорят что это всё дело на менеджерах, а не на кодерах и нужно дать причину кодерам трекать своё время, но меня с самого начала приучили делать это и я принял это как должное, как одну из обязанностей работы. Но тут всё таки нужно верить каждому на слово, если есть недоверие - этот метод не подойдет. Но он самый простой и легкий, написать такой сайтик вообще труда не составит.
Но допустим даже работник чуть приувеличил кол-во часов, вписал вместо 4 часа - 5 часов, это разве страшно? Вы же не платите почасово разработчику деньги за проделанную работу, а наоборот, платят вам клиенты. Как дело они не разбираются и такая практика применяется везде, у кого-то меньше, у кого-то больше, но в основном везде. А так в ИТ очень сложно определённо сказать сколько времени займет та или инная задача, ибо уровень квалификации у каждого человека разный, да и мало ли какое рабочее пространство, то никто не будет спорить 4 там часа или 5 часов надо оплатить. Ну это глупость.
Всё зависит от вашей компании, у нас работает такой метод и весьма успешно.
Я лично знаю какой прайс выставляется клиентам и когда проделываю работу на определённое кол-во единиц, сразу понимаю что я как минимум заработал для компании больше, чем мне выплатят за этот день и уже могу спокойно выполнять другие задачи, не загоняя себя.

Если оценка превышает запланированную более на 30 процентов

Люди разные, скорость работы не равна уровню квалификации.
Есть скоростные люди, которые быстро решают даже сложные задачи, но не способны создать архитектуру продукта, который потом будет комфортно поддерживать, обязательно налепят вещей, которые вроде как по всем стандартам прошли, а через год выясняется, что что-либо изменить - сложно.
Есть люди, которые просто работают медленно, по своей сути.

Как менеджер, вы должны учитывать этот момент, и составлять характеристику на людей, тасовать их в разные команды, назначать им разные задачи (или делегировать микро-таймменеджмент на тимлидов).

Если же хотите математику - готовьтесь к тому, что у вас будет большая текучка, пока вы не сможете укомплектоваться молодцами, одинаковыми с лица, то есть примерно одинаковыми. Но это займет уйму времени (то есть денег). Собственно одна из работ менеджера состоит в том, чтобы правильно распределиться ресурсами, а это в том числе и людьми.

Хм. Как же яростно народ отстаивает свое желание не сидеть на поводке :)

Опишу работу на галерах:
есть счетчик типа апворка (их хватает), трекает время с скриншотами. Разработчик меняет таски в трекере,
каждые 2 часа меняет мемо (комментарий в трекере), в трелло/жире меняет активную таску по мере выполнения. Одновременно в работе не более одной, внутри таски чекпойнты, требуемые для реализации для более четкого понимания.
Работа по аджайлу, скрам. Требуется планирование задач на спринт, примерная оценка в часах или условных единицах. Спринт - неделя или две. Каждый день стендап на 5 мин по итогам предыдущего дня и планинг следующего.
Каждый вечер письменный отчет о выполненных задачах и план на следующий день.
Менеджер проекта следит за прогрессом, если просадка по скорости - вовремя обращает на это внимание, с командой пробует найти решение проблемы либо оповестить заказчика о возникших трудностях.
Оплата - зарплата фикс за работу из расчета 8ч в день по счетчику. Овертаймы - отдельная такса.

Для чего - контора работает на выполнение заказной разработки. Предварительно идет оценка трудоемкости, исходя из планируемых часов выкатывается стоимость заказчику. Соответственно - контроль использованного на задачи времени важен и нужен для оценки менеджером и бухгалтерией - идет работа по плану или начинаем работать в убыток.
Эффективность методики - контора за 5 лет попала в топ 50 рейтинга ИТ по РФ, постоянный рост как проектов так и штата.
Работа не простая, либо становишься эффективным специалистом, либо гуляешь.

В компании тимлиды присматривают за подопечными, если возникают проблемы, ищут возможное решение, помогают.

Жесткий контроль процессов, результативности труда. Приветствуется рост знаний, проекты самые разнообразные.

Работать можно в любое время, оценка потраченных часов в конце недели. На халяву денег не заплатят.

Тут пишут 'успел в дедлайн' и прочую чепуху. Вопрос - кто устанавливает дедлайн в ваших конторах? Аджайл подразумевает самоуправление команд разработчиков. Цифры берутся не с потолка. Методики позволяют оценить скорость работы команды, на ретро делают обзор прошедших спринтов, найти решение каких либо проблем, выяснить, успеваем или нет. Все давно придумано, бери и пользуйся.
Если сотрудник не видит необходимости в отчетности, ему не важно, придет ли следующий заказчик, работает на отвали - что он тогда тут делает? Отчетность важна для прогнозируемого результата. Для нормальной работы необходимо сформулировать базовые ценности компании, которые ей позволят выжить и быть эффективной. Нет цели - четыре негра станцуют заупокой.

Как человек, постоянно забывающий логировать время в джире или делающий это задним числом и от фонаря, могу назвать следующии причины:
- не вижу смысла, ни разу не разбирали сколько был эстимейт и сколько заняло, а больше применения найти не могу
- достоверно это делать сложно, сложно даже достоверно статус задач поддерживать, (собственно на него и ориентируюсь, заполняя задним числом, но иногда откровенная лажа получается и тогда просто "рисуешь" правдоподобную картину)
- джира неудобный инструмент для этого, удобного вообще не нашёл

Советы, если это вам реально надо:
- автоматизируйте максимально, лучше всего ориентируясь на статусы задач в джире, обеспечив их достоверность (не допускать отсутствие активных задач, не допускать несколько активных задач одновременно, не допускать работу над "чужими" задачами и т. п.). Можно какого-то чат бота завести, который раз в час будет спрашивать "над какой задачей работаешь? "
- не просто объясните зачем это вам надо, а регулярно показывайте, что вы это используете для заявленных целей и заявленную пользу приносит, например на дэйли митингах разбирайте сколько часов команда отработала за прошедший день и выявляйте причины отклонений от плана

вы, если вы хороший менеджер, вы должны, наверное, понимать, что недоверие и чрезмерный контроль - становятся слишком накладными в плане трудозатрат. почитайте почему в китае работает практика "ту-ань-ши" кажется, когда в громадной компании всего 3 уроня управления - и у каждого менеджера по 40 замов, и почему этого нет в американо-европейской практике, где 1-2-3 зама - это "норма", и в итоге управленческий аппарат раздувается на множество слоев.

с разрабами нечто похожее. хотите точных отчетов - не доверяете им в некотором смысле, т.е. не верите, что они занимались чем то полезно осмысленным - вы будете тратить все больше и больше времени на эти самые отчеты и механизмы их обеспечивающие.

и будьте готовы к появлению графы в трудозатратах "заполнял журнал трудозатрат, 1 час в день".
более того, вы должны эту графу предложить. как минимум потому, что хороший руководитель проекта всегда выделяет в wbs отдельную графу работ под разванием "управление проектом". и в вашем случае, заполнение детальных отчетов о затратах на задачи - это как раз "управленческие расходы".

если такая графа вас устраивает, вы готовы тратить на это бюджет вашей зп - то вам осталось только объяснить людям смысл того, зачем вам нужны эти самые точные детальные отчеты с детальным разбиением по задачам.
потому что люди не будут делать бессмысленную (как минимум с их точки зрения) работу.
особенно инженеры.

вы сами то понимаете, какой толк, какая практическая польза от максимально детализированных отчетов?
почему вас не устраивает скажем 10% погрешность в этих значениях?

тречить задачи надо, нужна отчетность (хотя бы что бы бюджет понимать куда уходит), надо напоминать людям о том, что отчетность надо вести, но не надо перегибать с этим.
т.е, напоминать фрилансеру о необходимости отчитаться о затратах за вчера - это надо. увы, это, похоже, обыденная практика, да, такое часто бывает. но не надо делать из отчетности самоцель, и не надо надеяться что оно само будет работать и давать правдивые показатели.

и более того - это как раз и есть ваша работа как менеджера - следить за этим.
если бы все люди сами все делали автоматически и честно - тот же фрилансер всегда сам правдиво, точно и по расписанию все заполнял - вы стали бы ненужной прослойкой.

Оценивает задачу тот, кто будет её выполнять, с запасом, как ему комфортно, менеджер дополнительно прибавляет процент на риски (исходя из истории и опыта), и резервирует время и бюджет у заказчика.
Если не получается, чтобы задачу взял тот, кто оценил, тогда особенно важно, чтобы оценка была с запасом. Особенно если задача ушла неопытному разработчику - он её может выполнять вдвое-втрое дольше.

Разработчики записывают всё время по задаче, как им удобно, в свободной форме, но с привязкой к задаче. Это может быть непосредственно разработка, поддержка, аналитика, консультации - любая полезная деятельность должна быть оплачена.
Записывают как и когда им удобно, но заранее предупреждаются о сроке закрытия спринта/сделки, чтобы успели проставить время.
От закрытого времени напрямую зависит их (и не только их) доход, так что если что-то не записали - значит работали бесплатно, мотивация трекать более часто. Опять же нужна прозрачность, чтобы разработчики понимали, что от их записей зависит и их доход и фирмы.

Систем трекинга много, всяких.
Но это разработчики - так что в ходу много кастомных, внутренних, даже частных трекеров, которые сливают записи по api в кастомный корпоративный трекер.
Есть всевозможные клиенты для корпоративного трекера, в т.ч. веб-морда и mobile apps. Разрабатываем сами, кому как удобно, что-то приживается, что-то отмирает - живая экосистема.
Корпоративный трекер в свою очередь можно синхронизировать с редмайнами. Некоторые клиенты умеют заливать и в трекер и в редмайны, т.к. хранят данные в универсальном формате.

Оценка по комфортному времени позволяет разработчикам чаще укладываться в оценку, чем не укладываться. Поэтому почти с каждой задачи остаётся какой-то процент неиспользованного времени. Плюс оценка на риски менеджера.
В конце спринта все неиспользованные часы складываются, и из них покрывается овертайм.
Овертайм бывает на небольшом проценте задач, но иногда значительный: 200-300%. Не всё можно предусмотреть.
Почти всегда суммарного запаса часов хватает: например в спринте 10 задач, разработчики оценили их по 5ч каждую, менеджер заложил ещё 5ч на риски, итого 10ч каждая - зарезервировано 100ч на спринт, по итогу 2 задачи уши в большой овертайм, и скушали 30ч, 3 задачи ушли в овертайм, но уложились в риски - ещё 30ч, зато оставшиеся 5 задач уложились в оценку (без рисков), и на них ушло по 5ч - итого зарезервировано 100ч, затрачено 85ч(30+30+5*5), в оценку уложились, заказчик доволен.
Но так плохо редко бывает, в основном, т.к. разработчики оценивают комфортное время, реально уходит меньше оценки, т.е. оценили в 5ч, сделали за 3-4ч.
А те часы, что остались после покрытия овертайма, в счёт не выставляются, так что работа обходится как правило дешевле договоренностей. Небольшой приятный бонус для заказчика. Можно смело присваивать эти лишние часы, но долгосрочные отношения на обмане не построить, так что нафиг.
В случае совсем форс-мажоров, когда выходим за все риски - обсуждаем с заказчиком возможные варианты. Обычно заказчики идут на встречу, и выделяют дополнительные ресурсы.

Плюсы подхода: почти всегда укладываемся в бюджет, часто обходимся дешевле договоренностей, хорошие отношения с заказчиками.
Минус подобного подхода - приходится часть бюджета резервировать на риски, эта часть бюджета замораживается на два спринта, и может быть влита в 3й.
Как итог заказчику приходится закладывать бюджет чуть больше необходимого, но за счёт этого получаем намного более предсказуемое и стабильное планирование, к тому же в большинстве случаев этот небольшой переизбыток бюджета остаётся неиспользованным, и в среднем это бесплатно: то, что заморожено в текущем спринте, будет разморожено в следующем, и через спринт может быть пущено в дело.

Такая же проблема была, но тимлид контролировал и спрашивал ежедневно и все привыкли. Мы это не из за дисциплины делаем, а для улучшения планирования, корректировки коэффициентов и подсчёта стоимостей фичей, ну и непродуктивные задачи типа митингов режем

Очень интересный кейс. И не простой.
Но, во-первых, что-то у вас не так в организации проекта, если любой может лЁгко снести свой код за два дня до дедлайна. А где копии, а где контроль удаления?
Есть над чем поработать даже без относительно к ситуации, которую мы рассматриваем.

Во-вторых, проблема "выгорания" - это проблема психологии. Мне такие проблемы при удаленной работе попадались один раз. И честно говоря, даже при офисной работе с ними справиться не легко - но тут как-бы человек на виду, всегда можно поговорить на диванчике, за чашкой кофе. А на удаленке контакт значительно слабее, поэтому надо сказать , что и шансы на успех будут на порядок ниже.
Вы должны вообще-то говоря понять, что как только вы - как работодатель и как исполнитель - приняли решение об удаленной работе - все личные проблемы исполнителя остаются вне поля вашего внимания. Вы должны его об этом поставить в известность сразу-же. Это его плата, которую он несет в обмен на удобства его работы дома. Он должен понимать, что это не он, это вы согласились на то, что-бы он не тратил время-деньги на дорогу, на присутсвие в офисе, на завязывание галстука и шнурков на ботинках, на жесткий контроль часов и т.д. "Выгорел" - это не COVID-19 подхватил, не ногу сломал, упав с дивана и не кошка любимая заболела, срочно надо к ветеринару. "Выгорел? - ну пойди соберись и работай дальше. Не можешь - поезжай на Бали, расслабся, как вернешся - подавай резюме на свободную к тому моменту вакансию, тогда и будем решать". Тем более, что участник проекта из новых, а с новыми - всегда легче прощаться, чем с теми, с кем ты сделал десяток проектов. И после десятого совместного проекта я бы "выгорел" - еще потерпел-бы, дав человеку передышку. А если это начинается на втором-третьем месяце первого проекта?

Еще одно. "Выгорел" - это один кейс. "Сотрудник снес свой код, сорвав дедлайн" - это совершенно другой. Вообще-то говоря он нанес вам (вашей фирме) урон, материальный. Вы с ним об этом говорили? Вы ему объясняли, что срыв дедлайна - это удар не по абстрактной фирме или абстрактному заказчику - это в первую очередь удар по коллегам, работающим вместе с ним на проекте. Возможно - лишении их премии. Вы спросили его, как он собирается компенсировать этот урон? Что он вам ответил?

Пока писал - понял, что на самом деле тут таки таки два разных решения.

Первое, если бы просто "выгорел". Тут есть правило менеджмента "управляемость такая-же важная характеристика сотрудника, как его квалификация". И не важно, что "для своего уровня неплохой". Неплохой, но слабоуправляемый. Найдете другого, но впредь при приеме на работу смотрите не только на квалификацию, но и на его социально-психологические особенности. Поэтому алгоритм - "беседа - выяснение причин - и если не помогло - то прощание".

Второе - "удалил код". После такого - решение однозначно. Прощание без финансовой компенсации, без сожаления и без "простите меня пожалуйста".

Ну вот как-то так.
Удачи вам в решении проблемы.

А что вы собрались подтверждать пушем, устройство?)
Смысл СМС в том что подтверждается принадлежность номера телефона человеку, а пуш высылается на устройство, то есть пушем вы лишь подтвердите что тот кто пытается зарегистрироваться с этого телефона делает это с этого телефона)
Более дешёвые варианты это подтверждение регистрации по звонку - либо отвечаете на звонок и вам диктуют код, либо вам звонят со специального номера, четыре последние цифры которого и есть тот самый код, который нужно ввести

Например вот

Смотря что закладывается в понятие "прототипирование интерфейсов", если черно-белый набросок, то да - Axure RP.

Что касается UX/UI, рекомендую почитать книги, которые подойдут для менеджера проектов:

Майк Монтейро «Дизайн — это работа» - поможет грамотно презентовать дизайн проекты и научится руководить дизайнерами.
Психбольница в руках пациентов - Купер - подтянет навыки UX-проектирования, в основном увидите в ней проблемы из прошлого и как их можно решить. Очень будет полезно прочитать менеджеру проекта.
Не заставляйте меня думать - Алан Купер - просто библия, для всех кто связан с интерфейсами.

Эти три не больших книги, введут вас в курс дела и научат мыслить по другому, в области UX.

Можно токен передать таким образом:

@GET("/api/v1/datasets")
 Call<List<PostModel>> getData(@Query("id")int count, @Query("name") String resourceName, @Header("Authorization") String token);

Если хотите форматирование, как в системном приложении "контакты" - просто посмотрите, как это сделано в исходниках этого самого приложения.
Ссылка на git с исходниками