В этой статье Рэйчел Жилет собрала лучшие советы по продуктивности на 2015 год.Читать полностью »
В этой статье Рэйчел Жилет собрала лучшие советы по продуктивности на 2015 год.Читать полностью »
Вы когда-нибудь задумывались: “А сколько стоит пароход построить?”, “А сколько — дизайн-макет сделать?”, “А из чего складывается такая цена?”
Пароход — штука архисложная; его стоимость — это цена на материалы (металл, пластик и что там ещё нужно), оплата труда рабочих верфи, амортизация на износ оборудования, оплата инженерных изысканий и так далее и тому подобное…
А что с дизайн-макетом? Из чего складывается его цена? Ну, допустим, вложим в стоимость “амортизацию оборудования” — деньги на ПК и ПО, которые регулярно нужно обновлять. А что ещё? Остается, собственно, только оплата труда дизайнера-верстальщика. А как её рассчитать? Тут способов два: либо оплата за человеко-часы (сколько времени потратил — столько и оплатили); либо другой более распространенный подход — сдельная оплата (т.е. оценил бриф-ТЗ на макет, прикинул его сложность, назвал стоимость).
Что в первом случае (прямо), что во втором (косвенно), стоимость будет зависеть от времени, которое вы тратите на свою работу. А из чего складывается это время? Есть факторы внутренние: мотивация, навыки работы, муза, в конце концов… Они подвластны лишь вашей силе воли, тут дза-дзен и прочее самосовершенствование вам в помощь. Но остаются ещё и факторы внешние: от обстановки в рабочем кабинете до методологии, по которой вы работаете, — и с ними всё интереснее…
На тему заголовка недавно написано два поста Что дешевле: новое железо или труд разработчиков? и Почему нет простых решений о том, что лучше — купить серверов или оптимизировать код.
Почитал и решил, что не всё досказано даже в этих двух статьях.
Давайте посмотрим на конкретные варианты, чтобы понять абсурдность абстрактных рассуждений на эту тему.
Читать полностью »
Думаю, что большинство тех, кто внедрял у себя в командах тот или иной инструмент (особенно, если он родом из страны с другой ментальностью) согласиться, что внедрение не всегда проходит гладко. Однажды один академик мне сказал: «Ну а как ты хотел? Внедрение — это по определению вторжение чужеродного объекта в тело. Должно быть оСВОЕние. Делание своим!». С тех пор, для меня осознание того, что инструмент работает не совсем так, как задумывалось — является лучшим признаком освоения. Команда или сотрудник модернизировали по своему и начали использовать. И еще лучше, когда команда берет два разных инструмента и сама комбинирует их. Так произошло и в этот раз.
Из названия топика и картинки суть идеи будет сразу понятной. Ну а за подробностями, и связью с управлением продуктом, прошу под кат…
Продолжаем разговор.
В своем недавнем посте я привел несколько примеров, как тестировщик порой сам может упустить дефект, который был у него практически в руках. По недомыслию, неопытности, наивности, от усталости, в спешке – неважно. Сам. Программист и общая культура разработки могут, конечно, помочь – мол, не баг это, но все же, в описанных случаях их роль вспомогательная.
mtikhon в своей статье «Легкий способ пройти тестирование» прекрасно дополнил тот список «внешними» проблемами, влияющими на результат тестирования. Внешними – в том смысле, что они зарождаются не в отделе тестирования, а в прочих подразделениях, а еще чаще – где-то на стыках подразделений, при взаимодействии отделов. (Я понимаю, что не всегда под тестирование формально выделен специальный отдел. Но это косметическая разница, сути не меняет: тут речь скорее о разделении ролей)
mtikhon’у слегка попеняли в комментариях, что список проблем изложен, а легкий способ их обойти – нет. Он, в свою очередь, уже справедливо отметил, что «способы как правило разнятся очень сильно». Вот на этой мысли я и хочу потоптаться чуть подробней.
Пожалуй, пойду прямо по тем же пунктам.
Читать полностью »