Комментарии 127
НЛО прилетело и опубликовало эту надпись здесь
У всех почта должна проверятся с интервалом 1 минута (впрочем, если вы сторонник невмешательства в работу, можно всю срочную коммуникацию перенести в IM, и установить интервал проверки 30-60 минут).
Отвлекать и мешать сосредоточиться будет — мама не горюй. Еще Спольски писал, что после того как программист отвлекся, ему нужно около получаса чтобы вернуться к продуктивной работе.
Вы должны просматривать то что они закомитили, и спрашивать прямо если нужно: «Ты действительно потратил 8 часов на эти вот 10 строчек?»
А какая разница, сколько я потретил времени на 10 строчек, если я получаю деньги за результат, а не за потраченное время? 10 строчек на каком-нибудь хаскеле можно рожать и больше 8 часов.
Вообще говоря, есть такие понятия, как дисциплина и ответственность. И дисциплинированных, ответственных сотрудников такой тотальный контроль будет мягко говоря нервировать.
Если у человека задачи длинные и не требующие кооперации — то можно и без IM и без почты конечно (но это редкость).
Я разве говорю тотальный контроль? Если прогеры чувствуют что они делают что угодно, и результат один, все идет в разнос.
В статье написано, что строчки бывают разные. Бывают строки которые стоят 8 часов, бывают которые не стоят и 10 минут.
Я разве говорю тотальный контроль? Если прогеры чувствуют что они делают что угодно, и результат один, все идет в разнос.
В статье написано, что строчки бывают разные. Бывают строки которые стоят 8 часов, бывают которые не стоят и 10 минут.
В некоторых случаях оплата бывает не только за результат, а почасовая. Соответственно вопрос о актуальности 10 строчек за 8 часов вполне может быть очевиден.
И про дисциплину есть очень четкая фраза «скорость стада равна скорости самого слабого в стаде».
И про дисциплину есть очень четкая фраза «скорость стада равна скорости самого слабого в стаде».
Точно, надо в шапке дописать, что оплата почасовая :-) Понятно что если за результат — то не важно когда кто что делает :-)
Кстати, повременка тоже разная бывает. Например, я долго работал, когда учитывалось общее количество часов в неделю. Т.е. в течении недели ты можешь разбросать время как тебе угодно. Друг работал при учете часов в день, т.е. ты тоже обязываешься работать не менее N-го количества, но без «тотального контроля». Конечно, бывали моменты, когда «нужно вчера» и колбасишь всю ночь.
Это к тому, что для распределенной команды в разных часовых поясах можно предлагать удобный для всей команды режим работы, отчетности и оплаты.
Это к тому, что для распределенной команды в разных часовых поясах можно предлагать удобный для всей команды режим работы, отчетности и оплаты.
Про стадо — это как-то не эстетично :) Лучше так: команда сильна на столько, на сколько силен самый слабый в ней. Если бы я про стадо сказал своим подчиненным, думаю мой авторитет бы упал весьма ощутимо :)
Политики своё стадо вон называют политкорректно — электорат, надо нам тоже что-то придумать )
Никого не хотел обидеть и перед отправкой поста некоторое время стоял перед выбором — соблюсти ли историческую верность фразы или же пытаться перефразировать, ведь «команда сильна на столько, на сколько силен самый слабый в ней» не совсем верна т.к. слабого в этом случае скорее просто задавят и вытеснят, а вот если один не дисциплинированный подает другим пример — это действительно может заразить даже самых стойких.
Про подчиненных вы правы, такого конечно же говорить нельзя :)
Про подчиненных вы правы, такого конечно же говорить нельзя :)
скорость стада равна скорости самого слабого в стаде
Только в случае когда все задачи, выполняемые программистами связаны друг с другом. Если они не связаны или связаны слабо, то более быстрый просто сделает больше работы и получит больше денег.
Надо полагать, что дисциплинированный и ответственный человек понимает пользу и выгоду от дисциплины в команде, а потому с должным пониманием должен отнестись к дисциплинированному и ответственному тим-лиду.
А недостаток контроля даже самых ответственных расхолаживает.
А недостаток контроля даже самых ответственных расхолаживает.
а зачем отчеты, если время и задачи есть в трекере?
В этих багтрекерах время не отмечается.
Вариант с таймтрекером пробовали, с письмом больше ответственности (т.к. его надо отправлять до определенного времени, а таймтрекер — на него часто забивают).
Вариант с таймтрекером пробовали, с письмом больше ответственности (т.к. его надо отправлять до определенного времени, а таймтрекер — на него часто забивают).
проще поставить fogbuz или jira
для jira существует куча плагинов для оценки прогресса и построения красивых графиков по задачам
вся отчетность нужна менеджеру, а отчеты от программеров, это перевешивание работы с себя на других
для jira существует куча плагинов для оценки прогресса и построения красивых графиков по задачам
вся отчетность нужна менеджеру, а отчеты от программеров, это перевешивание работы с себя на других
Метрики не панацея :-)
Тут ведь нужны не графики, а личное понимание сотрудника, что если буду мало работать — будет сложно писать письмо вечером :-)
По письмо также видно когда оно было отправлено. Самодисциплина тренируется :-)
Тут ведь нужны не графики, а личное понимание сотрудника, что если буду мало работать — будет сложно писать письмо вечером :-)
По письмо также видно когда оно было отправлено. Самодисциплина тренируется :-)
А можете посоветовать что-то из плагинов для Jira для оценки прогресса и графиков по задачам? Есть какие-то, которые помогают планировать работу и считать сроки?
у нас используют таймтрекер. Выработалось правило: до 12ти часов дня нужно иметь полностью заполненные логи за вчера. Нарушителям не платят потраченные часы. Вот уже спустя год «небыло ни единого разрыва». Нужно просто преподнести до сотрудников это как аксиому.
Сначала были недовольства. Потом — устаканилось.
Сначала были недовольства. Потом — устаканилось.
В команде последнего проекта, где я участвовал (человек 12) всех предупреждали о необходимости писать ежедневные отчёты, и не раз. Не помогало. На репрессии люди естественным образом обижаются и уходят, а отчёты писать тогда мало кто начал.
Про себя: Поначалу я писал. На понятную менеджеру формулировку тратится дофига времени и сил. При том, что менеджер хороший и в технических знаниях даст мне фору много раз подряд, просто естественным образом не в теме всех деталей моих задач, которые знаю я. Я не стал игнорировать отчёты, просто объяснил по-человечески, что мне тяжело тратить кучу времени на вербальную формулировку своих действий — ведь порой исправить баг быстрее, чем описать его комментарием коммита. Так в коммите понимающему человеку виден контекст, где были произведены изменения, что в отчёте пришлось бы описывать отдельно. К тому же между задачами часто переключаешься, отвлекаешься на сопутствующие проблемы и проблемы других разработчиков, в итоге тяжело понять, сколько именно на что потратил.
У меня отчёт сейчас: количество потраченного времени всего и на какой род деятельности я его потратил в основном — правка багов, совместная работа, чтение документации или работа по тикетам.
Подгонка раздутием количества часов не интересна по причине отсутствия строгого контроля за их суммарным количеством. Хотя на самом деле следствие, видимо, обратное.
Выполнение задач с отчётом по часам мне не интересно по причине резкого падения качества моего кода в этом случае — если я напишу как получится там, где нужно взвешенное архитектурное решение или в силу гонки за часы откажусь от назревшего рефакторинга, требующего нескольких дней работы, в перспективе результат будет только хуже.
Если шефа интересуют подробности того, что я делаю или делал сегодня и он не может понять это по логам VCS и статусу тикетов — он спрашивает, в этот же день.
Итого:
Ежедневные отчёты с расписанием задач — страшное зло.
Менеджер обязан уметь читать логи VCS и статусы изменения тикетов.
Исследование деталей работ можно производить при подозрении на неудовлетворительную производительность или из технического любопытства, но не ежедневно.
Про себя: Поначалу я писал. На понятную менеджеру формулировку тратится дофига времени и сил. При том, что менеджер хороший и в технических знаниях даст мне фору много раз подряд, просто естественным образом не в теме всех деталей моих задач, которые знаю я. Я не стал игнорировать отчёты, просто объяснил по-человечески, что мне тяжело тратить кучу времени на вербальную формулировку своих действий — ведь порой исправить баг быстрее, чем описать его комментарием коммита. Так в коммите понимающему человеку виден контекст, где были произведены изменения, что в отчёте пришлось бы описывать отдельно. К тому же между задачами часто переключаешься, отвлекаешься на сопутствующие проблемы и проблемы других разработчиков, в итоге тяжело понять, сколько именно на что потратил.
У меня отчёт сейчас: количество потраченного времени всего и на какой род деятельности я его потратил в основном — правка багов, совместная работа, чтение документации или работа по тикетам.
Подгонка раздутием количества часов не интересна по причине отсутствия строгого контроля за их суммарным количеством. Хотя на самом деле следствие, видимо, обратное.
Выполнение задач с отчётом по часам мне не интересно по причине резкого падения качества моего кода в этом случае — если я напишу как получится там, где нужно взвешенное архитектурное решение или в силу гонки за часы откажусь от назревшего рефакторинга, требующего нескольких дней работы, в перспективе результат будет только хуже.
Если шефа интересуют подробности того, что я делаю или делал сегодня и он не может понять это по логам VCS и статусу тикетов — он спрашивает, в этот же день.
Итого:
Ежедневные отчёты с расписанием задач — страшное зло.
Менеджер обязан уметь читать логи VCS и статусы изменения тикетов.
Исследование деталей работ можно производить при подозрении на неудовлетворительную производительность или из технического любопытства, но не ежедневно.
«при желании можно и зайца научить курить» (с)
Это я к тому, что ваше начальство не сильно то и стремилось иметь заполненные логи.
У меня каждое утро начинается с заполнения логов за вчера. И получается, что вчера я не думал о гонке за часами или строгом следовании технического задания. Нужен рефакторинг — я его проводил. А утром сегодня я просто констатировал то, что вчера делал.
Еще не сильно понимаю чем отличается письмо с отчетом от заполнения логов. По-моему это одинаково сложно.
Вы не подумайте — я, как разработчик, с вами полностью согласен, что таймтрекер — это зло, он только мешает. Но это достаточно хороший способ контролировать своих сотрудников. Если шеф заболел/ушел в отпуск (например на недельки две) контроль за сотрудниками протекает без него.
Итого: таймтрекер — это отличный компромисс контроля сотрудников и эффективности кода.
Это я к тому, что ваше начальство не сильно то и стремилось иметь заполненные логи.
У меня каждое утро начинается с заполнения логов за вчера. И получается, что вчера я не думал о гонке за часами или строгом следовании технического задания. Нужен рефакторинг — я его проводил. А утром сегодня я просто констатировал то, что вчера делал.
Еще не сильно понимаю чем отличается письмо с отчетом от заполнения логов. По-моему это одинаково сложно.
Вы не подумайте — я, как разработчик, с вами полностью согласен, что таймтрекер — это зло, он только мешает. Но это достаточно хороший способ контролировать своих сотрудников. Если шеф заболел/ушел в отпуск (например на недельки две) контроль за сотрудниками протекает без него.
Итого: таймтрекер — это отличный компромисс контроля сотрудников и эффективности кода.
Время отмечается даже в последних версиях Мантиса. Но согласен, текстовое описание результатов труда дает куда больше информации, чем перевод issue в статус resolved.
На мой взгляд, Вы забыли упомянуть:
1. организовать общее информационное пространство для заказчика, лида, разработчиков, тестировщиков. Списки рассылки это хорошо, но большую часть материала там трудно искать, тем более отслеживать изменения.
Таким образом, нужен блог проекта, где публикуются новости, результаты встреч и т.п., нужна база знаний по проекту, где освещаются орг. вопросы, регламенты, правила и др. Единая точка входя для просмотра требований, задача, тестов, их результатов и т.п.
2. иметь и отслеживать некоторые оценочные показатели, которые помогут контролировать процесс, оценивать метрики, планировать будущие релизы, демонстрировать заказчику ход работ, сроки и текущее состояние проекта.
Уже больше двух лет работаем распределенно (заказчик, лид и тестировщик в одном городе, разработчики в нескольких других) и используем для организации и поддержки процесса систему DEVPROM. Лучшего решения нет.
1. организовать общее информационное пространство для заказчика, лида, разработчиков, тестировщиков. Списки рассылки это хорошо, но большую часть материала там трудно искать, тем более отслеживать изменения.
Таким образом, нужен блог проекта, где публикуются новости, результаты встреч и т.п., нужна база знаний по проекту, где освещаются орг. вопросы, регламенты, правила и др. Единая точка входя для просмотра требований, задача, тестов, их результатов и т.п.
2. иметь и отслеживать некоторые оценочные показатели, которые помогут контролировать процесс, оценивать метрики, планировать будущие релизы, демонстрировать заказчику ход работ, сроки и текущее состояние проекта.
Уже больше двух лет работаем распределенно (заказчик, лид и тестировщик в одном городе, разработчики в нескольких других) и используем для организации и поддержки процесса систему DEVPROM. Лучшего решения нет.
Система интересная конечно, но проприетарная, 350 уе на человека, при том что нет англоязычного интерфейса и оплаты в $ по кредитке(во крайней мере на первый взгляд)… Естественно хостинг на вашем сервере для серьёзного проекта не подойдет.
Цель проприетарности в стремлении идеологической целостности :) Однако, в будущем все может измениться.
Англоязычный интерфейс есть.
Что касается хостинга серьезных проектов, то Вы неправы, но в любом случае, следите за обновлениями, нам интересно не денег заработать, а разработать нужный инструмент, которым пользуются.
Скоро будем проводить бета-тестирование 1-го релиза, предполагаются бесплатные раздачи.
Англоязычный интерфейс есть.
Что касается хостинга серьезных проектов, то Вы неправы, но в любом случае, следите за обновлениями, нам интересно не денег заработать, а разработать нужный инструмент, которым пользуются.
Скоро будем проводить бета-тестирование 1-го релиза, предполагаются бесплатные раздачи.
извиняюсь, может быть не совсем понял то о чем вы пишите, но DEVPROM, как я понял, это аналог Basecamp?
если да, то каковы его преимущества перед бэйскэмпом?
если да, то каковы его преимущества перед бэйскэмпом?
детаельное описание выслал Вам лично, поскольку читатели не любят ссылок :)
в кратце, basecamp — это инструмент управления задачами, можно квалифицировать его как task manager, и подходит под любую групповую деятельность.
devprom — это существенное большее, и главное, заточенное под процесс разработки ПО, то есть обладает существенно большими возможностями и потенциалом для команд разработчиков ПО.
в кратце, basecamp — это инструмент управления задачами, можно квалифицировать его как task manager, и подходит под любую групповую деятельность.
devprom — это существенное большее, и главное, заточенное под процесс разработки ПО, то есть обладает существенно большими возможностями и потенциалом для команд разработчиков ПО.
Думаю достаточно любого тимтрекера, и время по задачам выставлять в нем, как и все вопросы по проекту.
Осталось найти заказчика :)
Осталось найти заказчика :)
Таймтрекер не так сильно стимулирует дисциплину :-) Не станет же тим лид в час X бежать проверять кто заполнил а кто нет? С письмами сразу ясно кто и когда :-)
Во-первых там может быть настроена рассылка на любое событие.
Во-вторых (в конкретно том, что я использую) есть система статистики в часах за день, месяц, год.
В-третьих при правильной мотивации и нормальном руководителе нет необходимости применения драконовских мер. А система учета времени важна в большей мере для планирования последующих работ и планов загрузки.
Поэтому всегда ясно «кто и когда». Бежать и проверять в час Х ничего не нужно. Это делается по итогам месяца, либо при дедлайнах.
Во-вторых (в конкретно том, что я использую) есть система статистики в часах за день, месяц, год.
В-третьих при правильной мотивации и нормальном руководителе нет необходимости применения драконовских мер. А система учета времени важна в большей мере для планирования последующих работ и планов загрузки.
Поэтому всегда ясно «кто и когда». Бежать и проверять в час Х ничего не нужно. Это делается по итогам месяца, либо при дедлайнах.
Сам тим лидер и главное у нас в команде это Дружба и Доверие, условие самое простое, у всех включен IM и устоновлен rAdmin.
1. Проснулись, узнали как у кого дела, сказали дружно начали.
2. Не много проманиторил для клиента, если друг сказал что работает а на манеторе redtube.com то сообщение в IM и он вернулся к работе.
Вообще хочу сказать что кроме взаимо доверия и Мониторинга, более не чего не надо.
На счет отчетов, так заказчик сам маниторит либа снимки смотрит, к концу дня по желанию общается с персоналом.
1. Проснулись, узнали как у кого дела, сказали дружно начали.
2. Не много проманиторил для клиента, если друг сказал что работает а на манеторе redtube.com то сообщение в IM и он вернулся к работе.
Вообще хочу сказать что кроме взаимо доверия и Мониторинга, более не чего не надо.
На счет отчетов, так заказчик сам маниторит либа снимки смотрит, к концу дня по желанию общается с персоналом.
Если сотрудник отстает по графику, а на экране redtube.com то пожалуй стоит искать ему замену, как можно скорее :-)
Лично я считаю что rAdmin это перебор, мы не в Китае :-)
Лично я считаю что rAdmin это перебор, мы не в Китае :-)
Ну не знаю у нас многим(4) нравится работать под радмином, желания отвлечься много, а так он устоновлен но не у всех включен, многие сами просят приконектится дабы проследить за выполнением работы.
Глянуть что сделано за день в svn — 2-5 минут на человека, а пасти всех по rAdmin — это жесть :-)
Безусловно иногда совместная работа это хорошо, но без причины тратить дорогое время тим лида не стоит :-)
Безусловно иногда совместная работа это хорошо, но без причины тратить дорогое время тим лида не стоит :-)
Извеняюсь но СВН это тормоза даже с AutoSVN, у нас ни единая душа на него не отвлекается, все занимаются воим делом, изредко сообщая над чем именно сейчас будут работать.
СВН больше подходит для заказчика который тупо все время обновляет папку на локалки просматривая новые файлы.
СВН больше подходит для заказчика который тупо все время обновляет папку на локалки просматривая новые файлы.
Не знаю о чем вы, сколько работаю с svn — все отлично и очень быстро.
Я к тому что без него работается еще быстрее, а так отвлекается как вы писали минуты на 2 на 5 + потерял настрой… Вроде мелочи, а раздражат многих, мы свн только в качестве проверки обновлений предлагаем.
На свн отвлекаться придется только раз в день
да да — а потом весело искать почему вдруг фича перестала работать — когда нет нормальных атомарных к оммитов с описанием что было сделано. Удачи вам в вашем нелегком деле создавания себе лишних проблем
А вы вообще систему контроля версий используете при разработке?
Цитирую отсюда: https://codingvault.org/forum/viewtopic.php?f=4&t=8&p=11
Итак, в каких ситуациях помогает (или даже спасает) использование VCS:
1. Сохранение истории кода — в любой момент времени мы можем вернуться к любому зафиксированному состоянию проекта. Машина времени — это не миф!
2. Синхронизация кода — при участии в проекте более одного человека система позволяет безболезненно производить слияние разных версий исходных текстов.
3. Сохранность кода — при использовании VCS исходный код лежит на рабочих машинах всех разработчиков + на сервере. В такой ситуации потерять код довольно сложно.
— От себя:
4. Если ломается функционал, который ранее работал, меня интересует, когда и почему он сломался. Я пишу тест на этот случай и перебором тестирую все версии от последней до момента, когда тест пройден. А вас интересует, откуда появляются баги в старом функционале? Как решаете?
5. Комментарии в CSV хорошо подходят вместо отчёта.
Если SVN — тормоза, ну попробуйте тогда git или mercurial, что ли.
Итак, в каких ситуациях помогает (или даже спасает) использование VCS:
1. Сохранение истории кода — в любой момент времени мы можем вернуться к любому зафиксированному состоянию проекта. Машина времени — это не миф!
2. Синхронизация кода — при участии в проекте более одного человека система позволяет безболезненно производить слияние разных версий исходных текстов.
3. Сохранность кода — при использовании VCS исходный код лежит на рабочих машинах всех разработчиков + на сервере. В такой ситуации потерять код довольно сложно.
— От себя:
4. Если ломается функционал, который ранее работал, меня интересует, когда и почему он сломался. Я пишу тест на этот случай и перебором тестирую все версии от последней до момента, когда тест пройден. А вас интересует, откуда появляются баги в старом функционале? Как решаете?
5. Комментарии в CSV хорошо подходят вместо отчёта.
Если SVN — тормоза, ну попробуйте тогда git или mercurial, что ли.
В радмине не вижу вообще не чего похожего на китай.
«Дружба и Доверие» и при этом обязательный шаринг рабочего стола?!
когда я знаю что за мной могут наблюдать у меня пропадает желание работать.
Когда я знаю что мне доверяют решить задачу так как я считаю правильным и тогда когда мне удобней ( с известными оговорками ) — я чувствую вдохновление и работаю спокойно и эффективно. И если мне нужно почаса на то чтобы прийти в себя и полазить в сети — это мое дело, я сам отработаю это когда вернусь в нормальное состояние.
Когда я знаю что мне доверяют решить задачу так как я считаю правильным и тогда когда мне удобней ( с известными оговорками ) — я чувствую вдохновление и работаю спокойно и эффективно. И если мне нужно почаса на то чтобы прийти в себя и полазить в сети — это мое дело, я сам отработаю это когда вернусь в нормальное состояние.
А как быть, если у разработчика стоит Linux? Насколько я знаю, под эту ОС Radmin'а как бы нет. Да и наличие второго компьютера или ноутбука никто проверить не сможет. Redtube.com вполне и на ноуте можно посмотреть :)
По моему опыту удаленной разработки есть пара дополнений:
1. обязательно нужно использовать общий чат в Скайпе в котором общается вся команда.
2. нужно определить «общее» время, когда все участники в онлайне. Т.е. жестко установить: «с 19.00 — 20.00 (мск) всем быть в скайпе!»
1. обязательно нужно использовать общий чат в Скайпе в котором общается вся команда.
2. нужно определить «общее» время, когда все участники в онлайне. Т.е. жестко установить: «с 19.00 — 20.00 (мск) всем быть в скайпе!»
А зачем заказчику общаться со всеми членами команды? мне кажется он должен иметь связь только с тимлидом
Иногда специалисту легче обьяснить на пальцах, чем тимлидеру на словах.
Я думаю тимлид должен тоже быть специалистом, к тому же заказчик не всегда очень понимает в ИТ, поэтому надо еще уметь объяснять. Плюс манера общения специалиста может оскорбить заказчика, после чего он просто не будет с работать с этой командой больше.
В общем я думаю что в любом случае связь должна идти через тимлида, даже пускай удаленный программист сам сформулирует тимлиду ответ на вопрос заказчика или то что он хочет сказать, а он уже потом передаст это заказчику.
В общем я думаю что в любом случае связь должна идти через тимлида, даже пускай удаленный программист сам сформулирует тимлиду ответ на вопрос заказчика или то что он хочет сказать, а он уже потом передаст это заказчику.
Заказчики бывают разные ) Есть такие которые могут что подсказать напрямую. Есть технически-продвинутые заказчики :-)
Более того, часто это даже вредит производству. Не всякий программер любит/умеет общаться с заказчиком. И в таких случаях есть риск не получить решения проблемы, а еще и усугубить моральную обстановку. Заказчик не понял, программер не смог объяснить, в итоге все не довольны. Или, не дай Бог, заказчик/программист поняли друг друга неверно, ведь все заказчики так любят давать задания программисту лично и на словах. Поэтому, я бы советовал избегать прямых контактов. Общение с заказчиком — прямая обязанность руководителя группы.
А не подскажете, каким образом собираются (и расширяются) такие команды, через фрилансовые сайты?
В моём случае — сначала находится тим-лидер(через цепочку знакомых), потом он на разных сайтах (фрилансерских, обычных по поиску работы) он находит нужных люди (но и знакомых тоже может :-) ).
Простите за грубость но это уже гавноменеджмент! Я про то что находится человек который говорит что все умеет, а сам ищет других людей остовляя себе весомый процент.
Вы ничего не поняли, и метаете кал :-)
В оффшорных командах с почасовой оплатой оплата ведется по каждому человеку отдельно.
Даже если тим-лид и оставляет себе часть, в этом его трудно упрекнуть, так работает весь оффшор (а крупные компании вообще себе оставляют иногда до 70-80%). Я так не делаю. У меня своя ставка, у подчиненных — своя.
В оффшорных командах с почасовой оплатой оплата ведется по каждому человеку отдельно.
Даже если тим-лид и оставляет себе часть, в этом его трудно упрекнуть, так работает весь оффшор (а крупные компании вообще себе оставляют иногда до 70-80%). Я так не делаю. У меня своя ставка, у подчиненных — своя.
Мой Колледж обращался к такой фирме, как же они были удивлены когда пришли в офис требовать что же случилось а менеджер, кусал ногти и отписывался прогеру кидале, а второй программист оказался 13 летним мальчишкой который на вопрос «сделать сможешь?» ответил, «я еще не знаю как!»
Я все это к тому что большинство подобных менеджеров не могут гарантировать исполнения работы от «СВОИХ» программистов, так как в большинстве случаев их даже не знают.
По мне Тим Лидер это Лидер и он должен быть лидером и чтобы таковым остоватся он должен знать всех тех кто позади него, только тогда он будет лидером когда за ним пойдут, а не когда ему дали по обещали денег 100000 он 50000 оставил себе а на оставшиеся 5000 пошёл искать людей на фрилансе который сделают то что надо за данную сумму.
Я все это к тому что большинство подобных менеджеров не могут гарантировать исполнения работы от «СВОИХ» программистов, так как в большинстве случаев их даже не знают.
По мне Тим Лидер это Лидер и он должен быть лидером и чтобы таковым остоватся он должен знать всех тех кто позади него, только тогда он будет лидером когда за ним пойдут, а не когда ему дали по обещали денег 100000 он 50000 оставил себе а на оставшиеся 5000 пошёл искать людей на фрилансе который сделают то что надо за данную сумму.
И берёт на себя тяжесть общения с невменяемым заказчиком?
И берёт на себя все риски?
И платит деньги вовремя и быстро, независимо от графика рассчёта заказчика?
И берёт на себя или перераспределяет задачи, которые я не могу выполнить в силу недостаточной квалификации?
В итоге — я знаю python, django и умею создавать сложные серверные приложения, я не хочу заниматься вёрсткой, дизайном, удоством интерфейса, контентом, переводом и прочими вещами, которые мне неинтересны. Строю архитектуру, пишу код, и на полученные деньги рассчитываюсь с кредитом за купленную квартиру. Сплю я спокойно, ведь все описанные выше проблемы — решает шеф.
Почему бы не взглянуть на это с такой сторны?
И берёт на себя все риски?
И платит деньги вовремя и быстро, независимо от графика рассчёта заказчика?
И берёт на себя или перераспределяет задачи, которые я не могу выполнить в силу недостаточной квалификации?
В итоге — я знаю python, django и умею создавать сложные серверные приложения, я не хочу заниматься вёрсткой, дизайном, удоством интерфейса, контентом, переводом и прочими вещами, которые мне неинтересны. Строю архитектуру, пишу код, и на полученные деньги рассчитываюсь с кредитом за купленную квартиру. Сплю я спокойно, ведь все описанные выше проблемы — решает шеф.
Почему бы не взглянуть на это с такой сторны?
В основном.
Удаленная работа и почасовая оплата — как-то не вяжется.
Уже 4 года у меня все вяжеться. Протирание штанов в офисе с почасовой оплатой тоже не вяжеться :-)
Я уже больше год работаю удаленно, каждый день, по графику (программер я), но почасовую оплату никак не представляю в такой работе. Кто посчитает эти часы? И как?
P.S. вяжется! вяжется! вяжется!
P.S. вяжется! вяжется! вяжется!
На основе ваших ежедневных отчетов. Тим лидер видит кто сколько делает.
Точно так же как и при работе в офисе — вроде у всех 8 часов, но все равно надо смотреть кто сколько делает.
Точно так же как и при работе в офисе — вроде у всех 8 часов, но все равно надо смотреть кто сколько делает.
Пункт про ежедневные отчеты — мне не нравится, это очень некомфортно и обычно после раб. дня сил нормально писать, что сделал желания/сил нет. К тому же некоторые с детства плохо умеют складывать слова в предложения)) и писать связный текст.
Ну и rAdmin упомянутый где-то в комментах — жесть.
Ну и rAdmin упомянутый где-то в комментах — жесть.
Работали и на удаленной основе и на on-site с людьми, остановились на on-site, все-таки психологические моменты нельзя списывать со счетов, технически работать удаленно уже давно не проблема.
самое главное в этом – адекватные исполнители. остальное опционально.
а уж если в процессе работы возникает желание пользовать radmin, то нужно сразу разбегаться друг от друга.
а уж если в процессе работы возникает желание пользовать radmin, то нужно сразу разбегаться друг от друга.
ну почему же вы так радмин ненавидите, приведу пример полезности.
В падлу что то заливать кудато, попросил включить радмин, приконектелись тот показал что оно работает и выглядит так, выключил радмин.
В падлу что то заливать кудато, попросил включить радмин, приконектелись тот показал что оно работает и выглядит так, выключил радмин.
Этот пример есть в тексте (с примером YuuGuu), есть масса софта для добровольного шаринга :-)
Добровольный шаринг для решения проблем безусловно удобен.
Добровольный шаринг для решения проблем безусловно удобен.
ненавижу? да с какого....?? нормальный, полезный инструмент.
однако когда его начинают использовать для контроля рабочего времени удаленных сотрудников… перспективы у такой команды смутные.
однако когда его начинают использовать для контроля рабочего времени удаленных сотрудников… перспективы у такой команды смутные.
Ненависть не к радмину, а ощущению, что за спиной надсмотрщик.
На данный момент меня больше привлекает работа в обществе/команде.
Автор признай, твои шакалы?! минусы ставят везде где только могут, даже в самых безобидных и правельных сообщениях которые минутой ранее имели +2, чего испугался что ли меня? Я просто правду говорю, а ты за топ держишся, да еще о ТимЛидирстве пытаешься говорить, фу как не красиво.
ps/ обидно только одно, временное ограничение.
ps/ обидно только одно, временное ограничение.
не думаю, что это автор
адекватная аргументация редко перекликается с минусованием неугодных)
адекватная аргументация редко перекликается с минусованием неугодных)
Нет, это не я. И «шакалов» у меня тут нет, я тут вообще 3-ий день :-)
Вы бы подумали над формулировкой сообщений и правописанием, а потом минусам удивлялись. Ваши мысли очень тяжело читать, и даже при всей их гипотетической правильности они просто могуть быть не прочитаны до конца )
да ты просто далбаеб :)
А у меня вопрос касательно где и как можно найти предложения о распределенной работе?
Выскажусь с колокольни простого разработчика.
Система контроля версий — благо с какой стороны не посмотри.
Багтрекер в комплекте с wiki — сильнейшая подпорка для памяти, сложно что-то оговоренное упустить.
Ежедневные отчёты с почасовой раскладкой — скорее зло. Обосную — зловредный баг ищется 4 часа, правится 1 строка. Возникает вопрос — зачем держать такого разгильдяя? Не будешь же указывать в отчёте мегабайты переворошённых дампов и десятки экспериментов по локализации вредной ошибки.
Гораздо лучше ежедневная раскладка заданий — минимум, норма и максимум.
Система контроля версий — благо с какой стороны не посмотри.
Багтрекер в комплекте с wiki — сильнейшая подпорка для памяти, сложно что-то оговоренное упустить.
Ежедневные отчёты с почасовой раскладкой — скорее зло. Обосную — зловредный баг ищется 4 часа, правится 1 строка. Возникает вопрос — зачем держать такого разгильдяя? Не будешь же указывать в отчёте мегабайты переворошённых дампов и десятки экспериментов по локализации вредной ошибки.
Гораздо лучше ежедневная раскладка заданий — минимум, норма и максимум.
Отчеты же читает тоже программист, он все понимает, что дебаг бывает неделями, что фиксится обычно одним символом :-)
Вполне нормально указывать в отчете «мегабайты переворошённых дампов и десятки экспериментов по локализации вредной ошибки». Более того обязательно указывать сколько времени потратил на чтение документации, связанных статей, просмотров примеров и т.п., т.к. это реальная работа. А если адекватный руководитель группы, то не грех указывать и время на самообучение и «интернет».
Что только не придумают чтоб не пользоватся BaseCamp.
А статья по делу, несоблюдение таких простых правил ведет к снижению результативности в несколько раз.
А статья по делу, несоблюдение таких простых правил ведет к снижению результативности в несколько раз.
Очень удобен для коммуникации команды IRC. Можно создавать каналы связанные с каждым проектом. В отличии от скайп отвлекает гораздо меньше.
Спасибо за статью. Ввиду того, что скоро придется окунуться во все это с головой читал с интересом и удовольствием.
Идея с шарингом десктопа очень понравилось. Удивительно простая, но насколько полезная! :) Вики, баг/таск-трекер и SVN — разумеется да.
Что касается SVN то есть вопрос — что используете вы? Какое-то решение на собственном сервере или же свободные площадки? Если можно, то прошу описать поподробнее :)
Идея с шарингом десктопа очень понравилось. Удивительно простая, но насколько полезная! :) Вики, баг/таск-трекер и SVN — разумеется да.
Что касается SVN то есть вопрос — что используете вы? Какое-то решение на собственном сервере или же свободные площадки? Если можно, то прошу описать поподробнее :)
Найти бы где-нибудь *реально* удаленный проект, было бы очень и очень здорово.
Что именно ищете?
Наиболее интересна JEE разработка, потому что в ней наиболее сильные скиллы. Есть неплохой опыт java + swing.
Если не java, то есть опыт в разработке на python и ruby (не rails). Ещё есть небольшой опыт в c++/qt для девайсов, то есть не для pc, а для некой железки под бизибоксом.
У вас есть предложения? Если да, то давайте пообщаемся по хабрапочте например.
Если не java, то есть опыт в разработке на python и ruby (не rails). Ещё есть небольшой опыт в c++/qt для девайсов, то есть не для pc, а для некой железки под бизибоксом.
У вас есть предложения? Если да, то давайте пообщаемся по хабрапочте например.
Угу, помню как лид (немец) чуть не плакал когда общался с двумя китайцами и индусом по скайпу (на тот момент я только наблюдал, т.к. сам выполнял малозначительную работу)
Какая схема работы по денежным переводам с заказчиком с программистами?
Спасибо
Спасибо
Меня интересовало вам зарубежные клиенты переводят деньги на счет
(как знаю здесь много сложностей возникает), на личную карточку кому-то или электронными деньгами.
Если по трудовой, то тогда получается, что все работающие находятся не так далеко — примерно в одной области, и фактически это не полноценные фрилансеры, а официально работающие удаленные сотрудники.
(как знаю здесь много сложностей возникает), на личную карточку кому-то или электронными деньгами.
Если по трудовой, то тогда получается, что все работающие находятся не так далеко — примерно в одной области, и фактически это не полноценные фрилансеры, а официально работающие удаленные сотрудники.
ТАк сверху же написано ) Как и у обычных оффшорных компаний — wire, с которым потом бугалтерия сама разбирается. Речь о фрилансерах не шла, речь шла именно об удаленных сотрудниках в команде которая работает долго.
Ну, у нас страна(Беларусь) как ваша область :-) А те кто подальше — тем тоже wire, но они зарегестрированны как предприниматели.
Ну, у нас страна(Беларусь) как ваша область :-) А те кто подальше — тем тоже wire, но они зарегестрированны как предприниматели.
НЛО прилетело и опубликовало эту надпись здесь
Спасибо за дельные советы! Вообще, я думаю что подобные отчеты нужно требовать и тим-лиду к офисным работникам, возможно менее строгий, т.к. все находятся в одном помещении. Контроль работников и их мотивация крайне необходимы, убедился самолично.
Сам так работаю. Схема как Вы и описали. А по другому и не получится.
Если честно, добрая половина из того, что вы описали не имеет ничего общего с реальной разработкой и тем более с деятельностью тим лида. То что вы описали больше похоже на роль надсмотрщика, причем не очень умного, работающего где-то на галерах или в упоротых банках.
Все члены команды должны высылать ежедневный отчет о потраченном времени по часам, не менее двух задач в день. Следует установить крайнее время отправки отчета (например 2 ночи мск). За опаздание с отчетом — выговор, если часто повторяется — придется искать замену.
А почему не дважды в день? :) Высылать, вы серьезно? В чем сложность поставить любой таймтрекер и пусть себе фоном тикает, в конце месяца и вы и разработчик получаете кол-во потраченного времени.
Будет неплохо договорится о ежемесячном премиальном бюджете для премирования наиболее старательных сотрудников.
Небось по количеству строчек будете определять "самых старательных"?
У всех почта должна проверятся с интервалом 1 минута
Почта в разработке зачастую присутствует как рудимент и тем более не встречал такого чтобы разработчики вели через нее коммуникацию.
... и по возможности комитить изменения к концу дня. Вы должны просматривать то что они закомитили, и спрашивать прямо если нужно: «Ты действительно потратил 8 часов на эти вот 10 строчек?»
Это совсем уже за гранью. Вы серьезно считаете что тим лид должен просматривать код своих подопечных каждый день? Сколько вы планируете тратить на это времени? Да и количество кода как правило не является отражением кол-ва затраченного времени.
За 14 лет в разработке, в роли как разработчика так и лида, при работе как из офиса так и удаленно, не встречал человека который был бы готов подписася работать на условиях описанных вами, более того, услышав об этом на собеседовании, бежал бы я от такой конторы.
Если в компании нет доверия к своим сотрудникам, то о какой качественной работе сотрудников может быть речь? Есть уйма инструментов в распоряжении у лида для того чтобы понять работают ли ваши сотрудники или нет.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Удаленная работа: тим-лиду и программистам