nDiki : 見積もり

2011年1月14日 (金)

DellTwitter サポート @DELL_SupportJP で好感度V字回復した

naney:5348202703

会社で使っている Dell Precision M90 が故障した。 電源を入れても白い画面が出るだけ。 ということで Dell テクニカルサポートで修理依頼をしようと Web サイトに行ったのだが、チャットサービスはつながらないし電話予約もエラー。それどころか電話番号検索ページもつながらず電話番号すら確認できず(Google Chrome でも Internet Explorer でも駄目)。 13:00 過ぎと一番混んでいる時間からかなと思いつつ、利用できない旨を Tweet したら @DELL_SupportJP から follow され @ 入電。 D で名前とサービスタグ番号、電話番号メールアドレスのやりとりをしたところ担当部署に連絡をとってくれて、担当から電話をもらうことができた。

この間注文時もそうだったんだけれど Dell Web サイトのサービスっていまいちだよなと思ってちょっと悪く思ってたんだけれど、人的な対応は素晴らしいね。 ということで好感度V字回復。

M90 の不具合

なお M90 の方はマザーボード・ビデオカード・液晶ケーブル・液晶モニタのどれかの問題の可能性が高いそうだけれども、前者2つは同モデルで不具合多発で無償交換対象とのことで1度サービスマンがきてくれることになった。 それで直らなければ後者の修理

Dell修理手続きが変わった

なお昨年末Dell修理手続きが変わったそうで、以前のように諸費用 + 部品代ではなくて、ヒアリング時に現象に対して見積もり金額を決めてその固定額での修理となるそうである。 以前みたいに引き取り修理で持っていってもらってから見積もりもらって修理を進めるか止めるかを決める(止めた場合でも費用はかかる)のではなくて、見積書の時点で進めるか止めるか(止めた場合は費用なし)になったらしい。

トータルで高くなったのか安くなったのかわからないけれど、「金額みて修理しないことにしたけど数万円は取られるよ」ということが無くなったのは良いね。

スポンサード リンク
[ 1月14日全て ]

2011年9月16日 (金)

今日のさえずり: 「家政婦のミタ」って何そのムズムズするタイトル!

naney:6152088359

2011年09月16日

[ 9月16日全て ]

2012年9月29日 (土)

今日のさえずり: exit(0);

naney:8034301473

2012年09月29日

[ 9月29日全て ]

2013年1月10日 (木)

毎日の仕事の計画を夜にするようにしたら捗っている

アジャイルな時間管理術 ポモドーロテクニック入門

年末からポモドーロテクニックをやってみているのだけれど、それにあわせて毎日の仕事の計画を夜にするようにしてみたところ捗ってる。

その日の最後の2ポモドーロ(25分 x 2)で、その日にやるべき残っているアクションをやっちゃったり、メールチケットの処理したり、GTD のデイリーレビューしたりして、その流れで翌日のポモドーロ数の見積もりと、ポモドーロでやるアクティビティだったりその他アクションだったりをチョイス。でその日のふりかえりをして、翌朝の朝会で話せるように書き出してる。

今までは朝に上のようなことをしていたんだけれど、そうするとあっという間にお昼になっちゃったりしてスタートダッシュしにくかった。でも前日の夜に済ませておくと朝はさらっと再確認したら本腰入れられて生産性がアップ。 「前日に計画しても、朝になったらまたメールが入ってたりスケジュールが追加されてたりで、それなりにチェックが必要」なのかなと思っていたんだけれど、実際やってみると前日の夜と次の日の朝の差分はほとんどなく問題なかった。

あとは夜にやれるかという点。例えば開発その他をガァーっとやってると「あらもうこんな時間」となってしまって続きは明日ということになり、2ポモドーロも確保できるのかなとちょっと思ってた。だけどポモドーロテクニックで回していると時間時間で区切るので、わりにスパッと切り替えられるので OK だった。これは面白い。

いや実は昨日はどうしてもその日にやっておきたい仕事があって、このパターンにしてから初めてふりかえりやら翌日のプランニングをしないで帰ったんだけれど、もはや気持ち悪いし今日の流れも若干いまいちだった。嫌。やっぱり夜やっとく方がいいや。

そんなこんなで自分、翌日の仕事の計画を夜にやっておくの意外にあっているかも。

[ 1月10日全て ]

2013年3月18日 (月)

ポモドーロテクニック終わり

アジャイルな時間管理術 ポモドーロテクニック入門

年末から仕事でポモドーロテクニックを取り入れてみていたんだけれど、どうも今の自分には合わないのでやめることにした。今まで通りストレートに GTD次の行動リストベース1本にする。

1日に何回かミーティングがあって、例えば 14:00-15:00 と 16:00-17:00 の予定になっていたりすると 15:00 から 16:00 の1時間が微妙なんだよね。2ポモドーロ入るわけだけれども、準備やら移動やらを考えると実際には2ポモドーロはできない。では1ポモドーロだけやって、あとは25分以下のアクティビティをやるかということになるのだけれども、やはり中途半端なんだよね。25分/5分 のリズムにのれる場合は有効なんだけどね。

ポモドーロテクニックをやって良いなと思ったのは見積もりの精度。タスクにかかる時間を過小評価しすぎるといのがよくわかった。あと25分毎に5分休むというのもメリハリがあって良い。なので一度は取り組んでみる価値があるよ。

ポモドーロテクニック原理主義からは離れるけれども、集中したい時にはポモドーロタイマーは活用していくつもり。

[ 3月18日全て ]

2013年11月29日 (金)

今日のさえずり: 「ガッツフィーリング」ってガッツ100%出し切った時の見積もりだと最初思ってた

2013年11月29日

[ 11月29日全て ]

2014年4月1日 (火)

プロジェクト開始時の開発見積もりは意味がない

140文字程度のなんとなくやりたいことで、すぐに工数見積もりが欲しいと言われたりするので「ソフトウエア開発55の真実と10のウソ」真実 9. を言及できるよう引用。

真実 9. ソフトウエア開発見積もりは、プロジェクトの開始時に実施する場合が非常に多い。これだと、要求定義が固まる前に見積もることになり、どんな問題がどこにあるかを理解する以前に予測するので、意味がない。従って、見積もり時期として適切ではない。-- ソフトウエア開発55の真実と10のウソ p.48

(日本語訳では「開発時」となっているけれども原文からすると「開始時」なので上記では修正)

Most software estimates are performed at the beginning of the life cycle. This makes sense until we realize that estimates are obtained before the requirements are defined and thus before the problem is understood. Estimation, therefore, usually occurs at the wrong time. -- Facts and Fallacies of Software Engineering Rovert L. Glass

既に2005年にも引用しているのだけれど、何も決まっていないのに工数を聞かれると今でもこれを思い出してしまう。

せめてユーザーストーリーぐらいまではまず書こう。

[ 4月1日全て ]

2016年4月17日 (日)

Toggl でタイムトラッキングするだけで時間の使い方が良くなる

image:https://www.naney.org/nDiki/2016/04/17/Toggl-Web.png

GTD では使える時間を基準に行動を選ぶ

GTD では次の行動を「状況」「時間」「エネルギー」「優先度」の順の基準で選びます。

今使っているタスク管理ツール Remember The Milk はタスクに予測時間を設定しておくことができます。そして検索やスマートリストで使える時間に応じたタスクをリストアップすることができます。

タイムトラッキングしてタスクの時間見積もり精度を上げる

ただこの予測時間の見積もりはだいたいこれぐらいかなと思って入力することがほとんどだったりします。もう少しきちんと入力できるようにタイムトラッキングしてどれぐらい時間がかかっているか実測してみることにしました。Remember The Milk にはタイムトラッキング機能が無いので、今回はタイムトラッキングサービスでは有名な Toggl 試してみます。

Toggl

サインアップすると Toggl サイト上でタイムトラッキングできます。Google Chrome 拡張を入れると Remember The Milk のタスクの横にも Toggl のボタンがついて1クリックでトラッキングの開始・終了ができるようになります。Remember The Milk のタスク名がきちんと Toggl のエントリの description に設定されるなど良くできています。これは便利。

スマートフォン向けアプリもあってそちらでもトラッキングの開始・終了ができます。以前ちょっとタイムトラッキングをしてみていた時(2007年前後)は Task Coach を使っていましたが、この頃は特定の PC でしかトラッキングできませんでした。スマートフォンの登場でかなり便利になりましたね。

タイムトラッキングすると時間の使い方が上手になる?

費やした時間を記録してあとで精査することで所要時間の見積もり精度を上げたり無駄な時間を見つけたりすることがタイムトラッキングの大きな目的だと思っていました。

しかし実際にやってみると

  • 「トラッキング中はネットサーフィンなどのような計測している実際のタスクとは違うことはしたくない」という気持ちになって集中してやるようになる。マルチタスキングもしなくなるのでコンテキストスイッチのコストが無くなる。
  • タイマーを設定することをイメージして「そもそもこんなことに時間を使わない方がいいな」と考えるようになり、無駄に思われる行動をやめるようになる。

など、ふりかえりをせずとも即行動に影響が現れたので驚きでした。家計簿をつけたり食べた物を書き留めるのと同じで、無駄に対する意識が高まるようです。

これは楽しいですね。しばらく続けてみることにします。

(画像https://blog.toggl.com/media-kit/ より)

[ 4月17日全て ]

2016年12月6日 (火)

第7回 エッセンシャル スクラムを読む会

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会7回目。今日は第7章 見積もりとベロシティ。

プロダクトバックログ見積もり

プロダクトバックログアイテム(PBI)の見積もりプロダクトバックログリファインメント(グルーミング)で行うアクティビティです。この時プロダクトオーナーやスクラムマスターは「実際に見積もる作業」には関わらないのがポイント。

見積もりの最大の目的は、話し合う過程でいろいろな気づきが得られるということだ。

でなるほどと思いました。見積もられたサイズよりも、見積もるという過程を重視しているんですね。

ストーリーポイント

PBI の見積もり単位としてストーリーポイントと理想日を紹介しています。ストリーポイントはあくまで相対値なのでそのチーム内でしか使えない値です。プランニングポーカーのところで

多くのチームでは、1回のスプリントでこなせる最大のサイズを13で表している。

としているので、これが一つの目安でしょうか。それからストーリーポイントはベロシティと対にならないとあまり意味をなさないですね。

理想日の方はいわゆる人日。

ベロシティ

ベロシティで計測するのはあくまでも生産量であり(デリバリーしたもののサイズ)であり、成果(デリバリーしたももの価値)ではない。

ここは当たり前な感じではありますが誤解してはいけないところ。

計測で出てくるベロシティは見積もりの(精度ではなく)正確性によってかなり揺らぎがあると思うのですが、このあたりはチームが学んでいくことで安定していくものなのでしょうか。ベロシティに幅を持たせて表すと良いとありますが、どれぐらいの幅に収まっていくのか興味があります。

それからベロシティが上がるかという話がありました。ストーリーポイントとしては相対値なので上がらないはずですよね。アウトプットの絶対量は増えていくと思いますけれど。

[ 12月6日全て ]

2016年12月7日 (水)

プランニングポーカーでプロダクトバックログアイテムの見積もり

プランニングポーカーを使ってプロダクトバックログアイテムの見積もりを初めてしてみました(私はプロダクトオーナーなので見積もる作業には関わらない立場)。「見積もりの最大の目的は、話し合う過程でいろいろな気づきが得られるということだ。」というの、なるほど納得しました。

[ 12月7日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

※内容は個人的見解であり所属組織とは関係ありません。

follow us in feedly

月別インデックス
Process Time: 0.060392s / load averages: 0.23, 0.22, 0.19
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker